Develop and Refine Your Backlog

Developing the Product Backlog

Backlog development usually starts with an initial list of user stories, architecture needs, or other items you identified during discovery.

The goal now is to turn that initial list into a backlog the team can actually use to guide development and other work. This process of developing a structured backlog improves clarity, traceability, and decision making. It helps the team see what each item supports, how items relate to one another, and which work needs to happen first.

hen developing the backlog, involve the people who will help deliver the solution, such as engineers, designers, testers, and users or their representatives. Their input keeps the backlog grounded in both stakeholder intent and technical reality.

The emphasis at this stage is not on documenting everything in full detail. It is on improving the backlog so the most important items are clear enough to discuss, prioritize, estimate, and refine further.

What the Backlog Contains

The backlog captures everything needed to deliver the solution. User stories are the most common format, but they are not the only type of item you will work with. A well-structured backlog typically includes several item types, each serving a different purpose.

Epics

Epics are backlog items too large to complete in a single iteration. They typically span multiple sprints and describe a capability or objective rather than detailed functionality. Epics sit near the top of the backlog hierarchy and connect detailed development work to larger outcomes or organizational goals.

Epics often include information that helps the team understand impact and plan effectively such as:

• Success metrics. Quantifiable targets for judging whether the epic delivered its intended outcomes, such as a percentage increase in user engagement or a reduction in processing time.
• Dependencies. Other work, capabilities, or features the epic depends on for successful implementation.

Example Epic for an Alumni Management System

Description. Create an alumni event management solution to organize, promote, and manage alumni events, strengthening community connections and increasing engagement.

Benefits. Streamline alumni event management processes, increase event attendance, and strengthen alumni community engagement.

Success Metrics.

• Increase alumni event attendance by 25%
• Reduce event planning time by 40%
• Improve alumni satisfaction scores for events by 15%

Epics help organize larger areas of work, but they are usually too broad to build in a single sprint. Before development begins, the team decomposes epics into smaller user stories that are easier to discuss, estimate, test, and deliver.

User Stories

Chapter 5 introduced user stories and the As a / I want / So that format for expressing what a user needs and why. As you develop and refine your backlog, stories need to be sized so that each one can be fully implemented within a single sprint. When a story is too large, you decompose it, breaking it into smaller, independent stories that each deliver value on their own. The Refining the Backlog section later in this chapter covers how to assess and improve story readiness, including how to apply the INVEST criteria more rigorously as stories move closer to development.

Technical Items

Technical items capture infrastructure, architecture, and other work that doesn’t directly deliver user-facing functionality but is still needed to build the solution, such as upgrading a database or updating existing code and systems.

Including technical items in the backlog ensures they are visible and managed alongside feature work. Without this visibility, technical needs tend to accumulate until they create delivery problems.

What to capture and define:

• Title or summary: A short name that makes the work easy to recognize in the backlog.
• Description: What needs to be done and why it matters.
• Rationale or driver: The need behind the item, such as performance, security, maintainability, scalability, reliability, compliance, or developer productivity.
• Priority: How important the item is relative to feature work and other technical needs.
• Risk or impact if delayed: What could happen if the work is not addressed.
• Dependencies: Related systems, teams, tools, decisions, or backlog items that affect the work.
• Acceptance criteria or completion criteria: How the team will know the technical item is complete.
• Estimate or size: The expected effort, complexity, or uncertainty involved.
• Owner or accountable role: Who is responsible for clarifying or leading the work.
• Related architecture decision or requirement: Any connected architecture requirement, quality attribute, ADR, spike, or technical constraint.
• Evidence or source: Where the need came from, such as a code review, production incident, security scan, stakeholder constraint, technical spike, or architecture discussion.

Bugs

Bugs are issues or defects in existing functionality. Including them in the backlog gives the team a clear picture of the work competing for each sprint, helping them weigh bug fixes against new feature development.

A useful bug report should make the issue easy to understand, reproduce, and verify after the fix.

What to capture and define:

• Title or summary: A short description of the issue.
• Description: What is going wrong and where it occurs.
• Priority: How soon the bug should be addressed relative to other backlog items.
• Severity or criticality: How serious the impact is, such as data loss, security risk, blocked work, degraded experience, or minor inconvenience.
• Who is impacted: The users, roles, customers, teams, or systems affected by the issue.
• How they are impacted: What the bug prevents, delays, confuses, or makes harder.
• What is impacted: The feature, workflow, data, integration, report, screen, or system component involved.
• Steps to reproduce: The specific actions needed to trigger the bug.
• Expected behavior: What should happen.
• Actual behavior: What happens instead.
• Frequency: Whether the bug happens every time, intermittently, or only under certain conditions.
• Environment: Where the bug occurs, such as browser, device, operating system, app version, test environment, or production.
• Evidence: Screenshots, error messages, logs, user reports, analytics, or support tickets.
• Workaround: Any temporary way users or support teams can avoid or reduce the impact.
• Related items: Connected user stories, releases, incidents, recent changes, dependencies, or technical items.
• Acceptance or verification criteria: How the team will confirm the bug has been fixed.

Spikes

Spikes are time-boxed research, prototyping, or investigation activities used to reduce uncertainty before the team commits to implementation. They are useful when a requirement is not yet clear enough to estimate, or when a technical approach needs to be explored before the team can decide how to proceed.

A spike should not become open-ended research. It should be focused on learning enough to make a decision, reduce risk, or prepare the related work for estimation and delivery.

What to capture and define:

• Title or summary: A short description of the uncertainty being investigated.
• Question to answer: The specific decision, risk, or unknown the spike is meant to clarify.
• Reason for the spike: Why the team needs this investigation before moving forward.
• Scope: What the spike will and will not explore.
• Time box: The maximum amount of time the team will spend on the investigation.
• Owner or participants: Who is responsible for doing the research, prototype, or analysis.
• Approach: How the team will investigate the question, such as a technical experiment, prototype, vendor review, API test, architecture discussion, or user research.
• Expected output: What the team should produce by the end, such as a recommendation, prototype, estimate, decision, trade-off analysis, or updated backlog items.
• Decision criteria: How the team will judge whether an approach is viable.
• Risks or assumptions being tested: The uncertainty the spike is intended to reduce.
• Dependencies: Tools, systems, data, people, or decisions needed to complete the spike.
• Related backlog items: The feature, technical item, bug, architecture requirement, or user story the spike supports.
• Completion criteria: How the team will know the spike is done.
• Follow-up actions: What may need to happen after the spike, such as creating new stories, revising estimates, updating acceptance criteria, writing an ADR, or changing the implementation approach.

Backlog Item Traceability

A backlog item gains meaning from its connection to the goal it supports, the user needs it addresses, and the architecture or quality requirements it must satisfy. Traceability is the practice of making those connections explicit and maintaining them as the backlog evolves.

At a minimum, each story should trace back to the goal or outcome it supports, the user need it addresses, and any architecture or quality requirements that apply. Its acceptance criteria should also reflect those connections where relevant. Stories that do not connect to a goal or specific user need should be assessed during refinement. If the team cannot explain who benefits or what goal the story supports, the story may not belong in the backlog yet.

Backlog tools can support traceability directly as stories can link to parent epics and epics can link to product goals. Individual stories can be tagged with additional information to help you identify, report on and manage backlog items related to a particular goal, user, feature or other aspect of your solution.

Traceability takes effort to maintain, but it pays back in three common situations. When priorities change, the team can identify the stories connected to a now-deprioritized goal and defer or remove them together, instead of searching through the backlog one item at a time. When a stakeholder asks whether a goal is on track, the team can show which stories address it, which are done, and which are still in progress. When an audit or compliance review asks how a requirement was addressed, the team can show the chain from requirement to story to acceptance test to released feature.

In regulated industries, such as healthcare, financial services, and government systems, traceability is often mandatory. A traceability matrix may be required to demonstrate that each regulatory requirement maps to specific implementation work and related tests. In less-regulated contexts, traceability is still useful because it helps the team confirm that backlog work remains connected to the outcomes it is supposed to support.

Refining the Backlog

Most backlog items begin as high-level entries linked to user needs, stakeholder requests, risks, or technical concerns. Requirements rarely arrive complete, instead they evolve as you learn more about users, technical needs, constraints, and dependencies (Ralph, 2015; Inayat et al., 2015).

Backlog refinement is the ongoing work of turning these initial entries into items that are specific enough to estimate, implement and test. This work typically happens during backlog refinement sessions, where the team reviews upcoming items, often with input from your users or other stakeholders.

During these sessions, the team:

• Selects items to review. Focus on the highest-priority backlog items that are likely to be delivered soon.
• Clarifies scope and intent. Ensure everyone understands the user story, its value, and the outcome it is meant to support.
• Breaks down large items. Decompose epics or large stories into smaller items that can be completed within a single sprint.
• Identifies dependencies. Surface technical needs, integrations, and external dependencies that may affect delivery.
• Adds or revises acceptance criteria. Define clear, testable conditions that describe when the work is complete.
• Estimates the item. Use relative estimation, such as story points or sizing, to understand the item’s complexity, effort, and uncertainty.
• Revisits priorities. Adjust backlog order based on value, risk, dependencies, estimated size, and what the team has learned.

By the end of refinement, the team should have a set of items that are clear enough to bring into sprint planning with an understanding of scope, priority, dependencies, acceptance criteria, and estimated size.

Refinement Cadence

How much refinement a team needs depends on the maturity of the backlog and the complexity of the work. Early in a project, when most items are still large and loosely defined, you may need more frequent sessions. Later, when the backlog is well groomed and the team has a stable rhythm, lighter-touch sessions may be enough.

When you walk into planning with items that are already well understood, estimated, and small enough to fit in a sprint, the planning session becomes a conversation about priorities and trade-offs rather than a scramble to clarify requirements.

How to Decompose Items

One of the most important refinement activities is breaking down epics and high-level stories into smaller items the team can discuss, estimate, and deliver.

Creating small, well-structured user stories that can be delivered within a single iteration helps teams reduce ambiguity, deliver working software faster, and manage dependencies more effectively (Cohn, 2004).

Use the following guidelines to help you split backlog items into smaller, actionable user stories:

• Start with the goal. Clarify the user need, business goal, or outcome the larger backlog item is meant to support. This keeps decomposition from becoming a mechanical exercise.
• Apply vertical slicing. Break work into thin, end-to-end slices that include the necessary interface, application logic, and data needs. Each story should produce working functionality that can be demonstrated and tested.
• Use user activities as a guide. If an epic involves a process, break it down by the natural steps in that workflow. For example, “Manage Alumni Events” might become “Create event,” “Publish event,” “Register for event,” and “View attendee list.”
• Identify variations and exceptions. After defining the main workflow stories, look for variations or edge cases that may need separate stories, such as “Cancel registration,” “Edit published event,” or “Notify user if registration fails.”
• Keep dependencies manageable. Break stories down so they can be developed, tested, and delivered with minimal dependency on other stories. A story does not need to be completely independent, but the team should understand what must happen before it can be completed.
• Consider architecture requirements. Identify performance, security, accessibility, compliance, reliability, or integration needs that affect the story. These may become acceptance criteria, technical items, or separate backlog items when the work is significant.
• Validate with the team. Review the decomposed stories together to surface assumptions, clarify open questions, and make sure the team has a shared understanding of the work.
• Ensure stories are sprint-sized. Each story should be small enough to design, build, test, and review within a single sprint. If a story is too large or uncertain, it may need to be split further or explored through a spike.
• Prioritize the first usable release. Decide which stories are essential for the first version of the workflow and which can be deferred. This helps the team avoid treating every story as equally urgent.

How to Prioritize Backlog Items

As discussed earlier in this book, prioritization is not a one-time decision. It is an ongoing process that helps the team focus on the backlog items that matter most to the organization, stakeholders, and people who will use the system.

During backlog refinement, priorities may change as the team learns more. For example new evidence from your research may clarify the value of a feature, stakeholder needs may shift, an unexpected dependency may appear, or a risk may need to be addressed before other work can move forward. Regulatory, compliance, security, or accessibility needs may also move an item higher in the backlog.

At this stage, the goal is not to reprioritize everything from scratch. Instead, the team should ask a few practical questions:

• What creates the most value next? Which items best support the product goal, organizational priorities, or user needs?
• What is time-sensitive? Are there deadlines, compliance needs, stakeholder commitments, or release windows that affect the order of work?
• What reduces risk or uncertainty? Are there technical, operational, or user experience risks that should be addressed before the team invests further?
• What unlocks other work? Are there dependencies, architecture decisions, integrations, or technical items that need to happen first?
• What is realistic for the team? Given the team’s capacity, skills, and current sprint goals, which items are ready enough to be considered for upcoming work?

Using Story Mapping to Inform Prioritization

A user story map can help the team prioritize backlog items in relation to the user’s workflow, not just as separate items in a list. As introduced in Chapter 5, a story map organizes stories around the major activities a user needs to complete.

During backlog refinement, story maps help the team decide what to build first. The goal is to find the smallest set of stories that still delivers something useful to users. Story maps also make dependencies easier to spot, since the team can see whether the chosen stories cover the full workflow from start to finish.

Priorities should be flexible enough to respond to new information, but stable enough to support sprint planning. Whether the team is using practical questions, a story map, or a formal prioritization method, the team should avoid changing priorities so often that the next sprint becomes unclear. A useful backlog gives the team confidence about what is most important next, while still allowing the product owner and team to adjust as they learn more.

Estimating Backlog Items

Estimation helps the team understand the relative size of backlog items before committing to delivery. It supports refinement, prioritization, release forecasting, and sprint planning by helping the team compare work, identify uncertainty, and decide what may be ready for development.

Estimation usually happens at two key points. During backlog refinement, the team estimates items at a rough level to compare size, surface uncertainty, and decide whether items are small enough for upcoming work. During sprint planning, the team looks more closely at selected items and confirms what it can realistically complete.

At the backlog stage, estimation is not about predicting exact timelines. It is about asking, “How large, complex, or uncertain is this item compared with the others?”

A backlog item is ready to estimate when it is clear enough, small enough, and well understood enough for the team to size it with reasonable confidence. If an item is too vague or uncertain, the team should clarify the item, break it into smaller stories, identify missing information, or create a spike to reduce uncertainty before estimating.

Many teams use relative estimation for backlog items. Instead of estimating in hours or days, they assign a size that reflects the overall effort, complexity, and uncertainty involved (Cohn, 2005). Relative estimates help the team answer questions such as:

• Which items are larger, more complex, or riskier than others?
• Which items may be small enough for an upcoming sprint?
• Which items need more clarification before the team can commit to them?
• Which items may need to be split into smaller stories?
• Which items may require a spike before implementation?

How to Estimate During Refinement

During refinement, the team should treat estimation as a conversation, not just as a number. A useful estimating discussion helps the team understand what the item involves, what assumptions are being made, and whether the item is ready for upcoming work.

The team should estimate collaboratively with the people who will help design, build, test, and support the work. Different perspectives help surface missing steps, hidden complexity, dependencies, and uncertainty.

As the team estimates, ask:

• Do we understand the outcome? Is the user need, business goal, or technical purpose clear?
• Do we understand what “done” means? Are the acceptance criteria or completion criteria clear enough?
• What work is included? Does the estimate account for design, development, testing, review, accessibility checks, documentation, deployment, and validation where relevant?
• What makes this item complex? Are there integrations, data changes, edge cases, architecture concerns, workflow impacts, or compliance needs?
• What dependencies could affect the work? Does the item rely on other systems, teams, approvals, data, tools, or architecture decisions?
• What is uncertain? Are there assumptions, unresolved questions, unfamiliar technologies, or unknowns that could change the size of the work?
• Is this small enough? Can the item reasonably be completed within a sprint, or does it need to be split?
• Is a spike needed? Is the uncertainty too high to estimate responsibly?

Use lightweight artifacts to clarify scope when needed. Sketches, workflows, simple data models, examples, or acceptance criteria can make the work easier to compare and help the team avoid guessing.

If estimates differ significantly, pause and discuss what each person is assuming. A large difference may reveal missing requirements, hidden technical work, misunderstood scope, or unresolved risk. The goal is not to force agreement on a number, but to build a shared understanding of the work.

When an item feels too large or unclear to estimate, split it into smaller pieces, clarify the acceptance criteria, or create a spike to reduce uncertainty. Estimates are based on what the team currently believes to be true, so it can also help to capture key assumptions and revisit them as new information emerges.

This keeps estimation focused on learning. The estimate is useful, but the conversation around the estimate is often more valuable.

Common Estimation Techniques

Teams can estimate backlog items in several lightweight ways. The right technique depends on how mature the backlog item is and how much detail the team needs.

T-shirt sizing. Items are grouped into broad sizes such as XS, S, M, L, or XL. This works well when items are still high level and the team needs a quick way to compare them without getting stuck in detailed discussion.

Affinity estimation. The team groups items of similar size together. This allows many backlog items to be estimated quickly by comparison rather than evaluating each item in isolation (Rubin, 2012). It can be especially useful when the team has a large backlog and needs an initial sense of relative size.

Planning Poker. Team members estimate independently, then briefly discuss differences. This works well when items are closer to delivery because it helps reveal different assumptions about the work.

In Planning Poker, each team member privately selects an estimate, often using story points. Everyone reveals their estimate at the same time. If the estimates are close, the team can usually agree on a size quickly. If the estimates differ significantly, the team discusses why. A higher estimate may reveal hidden complexity, risk, or missing work. A lower estimate may suggest that someone understands a simpler approach. After a brief discussion, the team estimates again until it reaches a shared understanding.

The goal of Planning Poker is not to negotiate the number until everyone compromises. The goal is to surface assumptions. If one person estimates a story as 3 points and another estimates it as 8, that difference is a signal that the team may not yet have the same understanding of the work.

Estimating Using Story Points. Story points are a common form of relative estimation. They describe the overall size of a backlog item by combining three factors:

• Complexity. How difficult the work is, including business logic, integrations, data needs, edge cases, and technical design.
• Effort. The amount of work required to complete the item, including development, testing, validation, review, and supporting activities.
• Uncertainty. What the team does not yet know, such as unclear requirements, unfamiliar technologies, unresolved dependencies, or untested assumptions.

Teams often use a Fibonacci-style sequence, such as 1, 2, 3, 5, 8, 13, and 21, when assigning story points. The increasing gaps between numbers reflect the fact that larger items are harder to estimate precisely.

A small estimate usually means the item is clear, limited in scope, and similar to work the team understands. A large estimate may mean the item includes more work, more complexity, more uncertainty, or some combination of all three. When an estimate is very large, the team should usually split the item, clarify it further, or investigate the uncertainty before treating it as ready for delivery.

As backlog items move closer to delivery, these rough estimates are refined. During sprint planning, the team looks more closely at selected stories, breaks them into tasks where useful, and confirms what can realistically fit into the sprint.

How to Refine User Stories with Acceptance Criteria

User stories capture requirements from the user’s perspective, but they are intentionally brief, including just enough information to be expanded before development begins.

Acceptance criteria describe the specific conditions, behaviors, or results a backlog item must meet before it can be accepted as complete. They give the team a clear target for development and provide a basis for testing. When the work is reviewed, the team, users, and stakeholders use the criteria to decide whether the solution behaves as expected.

How to Develop Acceptance Criteria

Creating effective acceptance criteria involves:

• Collaborate with your stakeholders. Stakeholders and the development team should define acceptance criteria together. This helps surface assumptions, reduce ambiguity, and make the criteria more useful.
• Use clear, unambiguous language. Acceptance criteria should be written in simple, precise language that all stakeholders can understand. Avoid technical jargon unless necessary and ensure terms are clearly defined.
• Define quality attributes. Acceptance criteria should capture and define performance, security, accessibility, and other quality attributes that impact the user experience and solution performance.
• Make criteria testable. Each criteria should be verifiable through testing. This means including specific, measurable outcomes rather than subjective statements.
• Keep criteria independent. Each acceptance criterion should be testable on its own when possible. Reducing dependencies between criteria makes development and testing easier to coordinate (Crispin & Gregory, 2009).
• Review and validate with stakeholders. Stakeholders and users should review and agree on acceptance criteria before development begins as this sets expectations of what the story must achieve and helps reduce rework.

Example Acceptance Criteria

The following example mixes functional expectations with quality attributes, such as accessibility, performance, reliability, security, and auditability.

User Story

As an event organizer, I want to create and publish alumni events with details that encourage alumni to sign up, so that I can increase participation.

Acceptance Criteria.

• The system must allow the organizer to create a new event with the required details outlined in the event form prototype.
• The organizer must be able to upload optional materials (e.g., images, PDFs, promotional flyers).
• Once created, the event should be publishable to the alumni portal and/or email newsletter.
• Alums must be able to view the event details and sign up with a single click (registration form or RSVP button).
• The system should automatically update event capacity if a maximum attendance limit is set.
• The organizer should be able to edit or cancel an event after publishing, with notifications automatically sent to registered alums.
• Event pages must comply with WCAG 2.1 AA accessibility standards.
• Publishing an event should take less than 2 seconds under normal system load.
• Alumni event pages should load within 2 seconds.
• If the system is unavailable at the time of publishing, the event should automatically publish once service is restored.
• Sign-up records must not be lost if the system crashes; data integrity should be guaranteed.
• Only authenticated and authorized event organizers can create or modify events.
• All event creation and edits must be logged with the organizer ID and timestamp.

Using Behavior-Driven Development (BDD) to Write Acceptance Criteria

You can also write acceptance criteria as structured Given–When–Then scenarios, an approach called Behavior-Driven Development (BDD). Each scenario describes a specific interaction:

• Given: sets the initial state or context (e.g., a user is logged in).
• When: describes the action being performed (e.g., the user submits the form).
• Then: states the expected outcome (e.g., the system saves the data and confirms success).

Like other acceptance criteria, these scenarios are developed in collaboration with stakeholders to agree on the desired behavior, capture it in clear, natural-language statements, and write one or more scenarios for each user story.

This format strengthens communication, reduces misunderstandings and defects, and makes acceptance criteria directly testable through automated testing, though it requires discipline and some upfront effort to adopt effectively (Pereira et al., 2018; Arredondo et al., 2023).

Example Acceptance Criteria in BDD Format

User Story

As an event organizer, I want to create and publish alumni events with details that encourage alumni to sign up, so that I can increase participation.

Acceptance Criteria using BDD

Scenario 1: Successfully publishing an event

• Given I am logged in as an event organizer
• And I have entered a valid event title, date, location, and description
• When I click “Publish event”
• Then the event is saved in the system
• And the event becomes visible to alumni on the events page

Scenario 2: Missing required details

• Given I am logged in as an event organizer
• And I leave the event title blank
• When I try to publish the event
• Then I see an error message telling me the title is required
• And the event is not published

Scenario 3: Alumni registration enabled

• Given an event has been published
• When an alumnus views the event page
• Then they should see a “Register” button
• And they can submit their details to sign up for the event

Definition of Ready

A Definition of Ready (DoR) lists the minimum conditions a backlog item must meet before the team pulls it into a sprint. Items that do not meet these conditions stay in the backlog for further refinement.

Having an explicit, agreed-upon set of readiness criteria can help prevent the team from pulling in items that are too vague, too large, or too poorly understood to finish.

A typical Definition of Ready includes conditions like these:

• The item has a clear user story or problem statement.
• Acceptance criteria are defined and testable.
• The item is small enough to complete within a single sprint.
• Dependencies have been identified and are resolved or planned for.
• The team has discussed the item and has a shared understanding of what “done” looks like.
• Any relevant non-functional requirements (performance, security, accessibility) are captured.
• The item has been estimated.

Maintaining the Backlog

A backlog that only grows becomes harder to use. As old, unclear, or low-value items accumulate, the team can spend more refinement time sorting through entries than making decisions about what should be built next.

Maintaining an effective backlog means periodically reviewing the backlog to archive or remove items that have sat untouched for several sprints, re-estimating items whose context has changed, and flagging items that have been deferred repeatedly. If an item has sat through several sprints without moving up in priority, ask whether it still matters. If the answer is no, or if no one can explain what it is for, remove it. You can always re-create it later if the need resurfaces.

Some teams schedule a quarterly backlog cleanup alongside their regular refinement cadence. Others fold this review into every refinement session by spending the last few minutes scanning the bottom of the backlog. Either approach works, the goal is to keep the backlog short enough that every item in it is something the team could plausibly work on in the foreseeable future.

Handling New Information and Change

As you capture new requirements, stakeholder requests, bugs, and other backlog items, the backlog needs to absorb that information without losing its structure.

When something new arrives, you need to decide whether it warrants immediate backlog entry, whether it modifies an existing item, or whether it can wait for the next refinement session. Not everything that feels urgent belongs at the top of the backlog and you should assess whether new information changes the priority of existing work, or introduces something the team needs to address before the next sprint.

Using AI to Help Develop and Refine the Backlog

Generative AI tools can help teams draft, review, and improve backlog items. They can suggest user stories, identify vague language, generate possible acceptance criteria, surface missing quality concerns, and check for duplicates. Used well, AI can make refinement more efficient. Used poorly, it can produce polished but unreliable backlog items that the team has not actually discussed or validated.

AI should support backlog refinement, not replace it as the goal of refinement is not just to produce better-written stories, it’s also to help the team build a shared understanding of the work.

Use AI as a reviewer, not a replacement for team discussion.

A useful approach is to draft the backlog item with the team first, then ask AI to review it. LLMs can help evaluate user stories against quality criteria such as INVEST. They can identify unclear structure, missing benefits, vague language, and possible duplicates that a simpler checklist may miss (Perkusich et al., 2025; Bashir et al., 2025). They can also suggest quality or architecture concerns that may be implied but not stated, such as privacy, accessibility, performance, or security needs (Yamani, Aljedaani, & Aljedaani, 2025).

Give the model project context.

Generic prompts usually produce generic backlog items. AI works better when you provide examples from your own backlog, describe the product or system, and define important domain terms (Bashir et al., 2025). This context is especially important when decomposing larger backlog items. With enough project context, AI is more likely to suggest story splits that reflect user value. Without it, the model may split work by technical layer, such as database, API, and interface work, rather than by meaningful user outcomes (Wijaya, Dam, & Mougouei, 2025).

For example, instead of asking:

Break this epic into user stories.

A better prompt would be:

Review this epic for an alumni event management system. Break it into user stories that each support a user goal or workflow step. Avoid splitting only by technical layer. Identify any assumptions, missing acceptance criteria, and possible architecture concerns.

Use AI to improve acceptance criteria.

AI can help generate or review acceptance criteria, but the team still needs to decide whether the criteria are correct. A model may suggest useful test conditions, edge cases, or error states the team missed. It may also invent requirements that were never discussed. Always treat AI-generated criteria as draft suggestions, not as approved requirements.

A useful prompt is:

Review these acceptance criteria. Identify anything vague, difficult to test, missing, duplicated, or based on an unstated assumption. Suggest revisions, but do not add new requirements unless you label them as assumptions.

Be cautious with prioritization.

AI can help teams think through priority, but it should not decide what matters most. Studies of LLM-assisted requirements prioritization suggest that practitioners may feel more confident after reviewing AI recommendations, even when they do not substantially change their rankings (Pir, Berntsson Svensson, & Inayat, 2025).

Use AI-generated priority suggestions as prompts for discussion. The team still needs to weigh value, risk, dependencies, learning needs, stakeholder priorities, and organizational goals.

Additional Risks related to AI usage

Watch for these common risks when using AI to help with backlog development and refinement:

• Hallucinated requirements. AI-generated stories and acceptance criteria can sound polished even when they include needs, constraints, or assumptions that were never validated.
• Compliance exposure. In regulated settings, prompt instructions are not a substitute for legal, security, accessibility, privacy, or compliance review. LLMs do not always stay within regulatory boundaries, even when explicitly asked to do so (Weissman, Mankowitz, & Kanter, 2025).

AI can widen the team’s view of the backlog, but it should not decide what belongs in it. The team remains responsible for validating needs, making trade-offs, and deciding what is ready for development.

Best Practices

The following practices help you keep the backlog useful, current, and connected to the work the team needs to do.

• Sequence items by dependencies. Identify stories that depend on others and order them so prerequisite work comes first. This reduces rework and avoids blocking the team mid-sprint.
• Prioritize by value and risk. Order items based on their value, user impact, technical risk, and dependencies. Items with high uncertainty or high risk often benefit from being addressed earlier, when there is more room to adjust.
• Make architecture requirements visible. Security, reliability, performance, accessibility, and compliance requirements are easy to overlook during refinement. Capture them as explicit acceptance criteria or standalone backlog items so they compete for priority alongside feature work.
• Refine ahead. Stay one to two sprints ahead so the team is prepared for sprint planning and development of high priority items
• Keep the backlog lean. A backlog with hundreds of items is a backlog no one reads. Regularly archive items that are unlikely to be built. A shorter backlog is easier to prioritize, easier to scan, and more likely to reflect what the team actually intends to deliver.

Wrap Up and What’s Next

You started this chapter with a loose collection of needs, technical concerns, and early ideas. You now have a structured backlog with items that are typed, decomposed, estimated, traceable, and assessed for readiness.

The next chapter picks up where refinement leaves off. Once items are ready, the team selects a set for the next sprint, breaks them into tasks, and begins the cycle of building, tracking, reviewing, and improving that drives iterative delivery.