Developing and Refining Your Backlog

The product backlog brings user needs, technical work, architecture requirements, risks, and other delivery tasks into one place, making the work visible so the team can refine, order, and adapt it over time.

In this chapter, you will learn how to structure a backlog, work with different types of backlog items, refine items so they are ready for delivery, and make sure user needs and architecture requirements remain visible as the backlog evolves.

Developing the Product Backlog

Backlog development begins with the needs, requirements, risks, and potential work identified during discovery. These may include research questions, descriptions of goals and capabilities, high-level user stories, technical work, defects, and other items the team may need to address. At this stage, the backlog is provisional and will often contain items with different levels of detail.

Developing the backlog involves working with the people who will help design, build, test, operate, and use the solution. Engineers, designers, testers, subject-matter experts, and users or their representatives can identify missing work, challenge assumptions, clarify feasibility, and help ensure the backlog reflects both stakeholder intent and technical reality.

You gradually organize, clarify, decompose, and prioritize these items so the backlog can guide development and related work. This process helps the team understand what each item supports, how items relate to one another, which dependencies or gaps need attention, and what work should happen next. It also creates traceability between stakeholder needs, product goals, requirements, and the work the team delivers.

What the Backlog Contains

The backlog captures everything needed to deliver the solution. User stories are the most common format, but you may also work with several other item types, each serving a different purpose. A well-structured backlog typically includes several item types, each serving a different purpose.

Epics

Epics are large backlog items that describe a significant capability or organizational outcome or large piece of work. They are usually too large to complete in a single iteration and are broken down into smaller user stories before implementation.

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:

• Description. A brief description of the Epic.
• Benefits. Describe the benefits of the work related to the Epic.
• 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%

Before development begins, the team decomposes epics into smaller user stories that are easier to discuss, estimate, test, and deliver.

User Stories

User stories describe a need or capability from the perspective of a user, including what they want to accomplish and why it matters. As you develop and refine a user story, use the INVEST criteria to assess its quality.

• Independent. The story stands on its own and can be scheduled in any order, without waiting on other stories. When decomposing an epic, check that the resulting stories do not depend on each other in ways that force a fixed sequence.
• Negotiable. The story is an invitation for discussion, not a fixed contract. Details are worked out between the team and stakeholders as understanding grows.
• Valuable. The story delivers a clear benefit to a customer or the business. If a decomposed story has no standalone value, reconsider how it was split.
• Estimable. The team has enough detail to size the effort. A story the team cannot estimate usually signals missing information or hidden complexity that needs clarification.
• Small. The story fits within a single sprint. This is the test that most often triggers decomposition during backlog refinement.
• Testable. The story has clear acceptance criteria, so the team knows when it is done. A story that cannot be tested is not yet ready for 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 that 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, maintain those three links for every story. 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.

You can use backlog tools to support traceability by linking related items. For example, a user story can link to a parent epic, and the epic can link to a product goal or outcome. You can also often use tags or custom fields (depending on the tool) to identify and report on items associated with a particular goal, user group, feature, requirement, risk, or other aspect of the 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 (Inayat et al., 2015; Ralph, 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 you and the team review upcoming items, often with input from 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 backlog’s maturity 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 refined and the team has a stable rhythm, lighter-touch sessions may be enough.

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

Prioritization is ongoing. It keeps the team focused 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 lets the team prioritize backlog items against the user’s workflow organizing stories around the major activities a user needs to complete (Patton, 2014).

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, refines initial estimates, and confirms what can realistically fit into the sprint.

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, as the discussion helps the team understand what the item involves, what assumptions are being made, and whether the item is ready for upcoming work.

You should estimate collaboratively with the people who will help design, build, test, and support the work as these different perspectives help surface missing steps, hidden complexity, dependencies, and uncertainty. Estimates are typically based on what team members understand what’s required, so it can also help to capture these as part of the discussion.

As you and the team estimate items, 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?

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.

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.

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.

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.

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.

How to Refine User Stories with Acceptance Criteria

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

To develop effective acceptance criteria:

• 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 criterion 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 combines functional and quality expectations without turning one story into a complete system specification.

User Story

As an event organizer, I want to publish an alumni event so alumni can view it and register.

Acceptance Criteria

• The organizer can save an event with a title, date, location, description, and registration capacity.
• The system identifies missing required information before publication and explains what must be corrected.
• A published event appears on the alumni events page and displays its current registration status.
• Only authorized event organizers can create, edit, publish, or cancel an event.
• Event creation, publication, edits, and cancellation are recorded with the user ID and timestamp.
• The event page meets the accessibility standard required by the organization.
• Under the defined normal-load test, 95% of event pages load within two seconds.
• If publication fails, the event remains unpublished and the organizer receives a clear error message without losing entered information.

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

You can also write acceptance criteria as structured Given–When–Then scenarios. This format comes from Behavior-Driven Development (BDD), a practice in which the team and stakeholders use concrete examples to agree on how the system should behave before development begins. Each scenario describes a specific interaction:

• Given sets the initial state or context, such as a user being logged in.
• When describes the action the user or system performs.
• Then states the expected outcome.

You can also use And to add further conditions, actions, or outcomes.

Like other acceptance criteria, BDD scenarios should be developed collaboratively with stakeholders and the development team. Each scenario should describe one clear example of the expected behavior using language that both technical and nontechnical participants can understand.

Given–When–Then scenarios can also support automated testing when they are connected to suitable testing tools.

Example Acceptance Criteria in BDD Format

User Story

As an event organizer, I want to publish an alumni event so that alumni can view it and register.

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 select “Publish event”
• Then the event is saved
• 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 have left the event title blank
• When I try to publish the event
• Then I see a message explaining that the title is required
• And the event is not published

Scenario 3: Alumni registration is available

• Given an event has been published
• And I am logged in as a registered alum
• When I view the event page
• Then I see a “Register” button
• And I can submit my details to register 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. You spend more time sorting through entries than deciding what to build next.

Maintaining the backlog means periodically reviewing lower-priority items to identify anything that is outdated, duplicated, poorly understood, or no longer worth pursuing. You may also need to revise items when their context has changed or reconsider items that have been deferred repeatedly. Ask whether the need still matters, whether the item is clear enough to be useful, and whether it is realistic that you will act on it. If not, archive or remove it. You can always create a new item if the need resurfaces.

You might schedule a quarterly backlog cleanup in addition to regular refinement sessions. Alternatively, you could spend a few minutes reviewing lower-priority items during each refinement session. Either approach can work. The goal is to keep the backlog relevant, understandable, and focused on work you might realistically undertake.

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

Recent research suggests that generative AI may provide a useful first-pass review of your backlog items, helping identify vague or inconsistent language, assess stories against quality criteria such as INVEST, and suggest possible rewrites (Levy et al., 2026).

However, research also identifies several limitations:

• False positives are common. Models may flag acceptable wording or identify problems that do not exist. In one evaluation, approximately half of the issues identified by the best-performing model were not genuine defects.
• Model size does not predict review quality. A smaller model optimized for the task outperformed a larger general-purpose model in one evaluation.
• Cross-story reasoning remains weak. Models may review individual stories effectively but struggle to identify duplicates, overlaps, dependencies, or inconsistencies across the backlog.
• Models can introduce unsupported assumptions. They may add project details that were not provided or criticize a story because it does not follow a preferred template rather than because it contains a genuine defect.
• Agreement may rest on different reasoning. A model and an experienced practitioner may agree that a story needs revision but disagree about why. The model may identify a formal rule violation, while the practitioner identifies missing context or unclear intent.

As a result, treat AI review as an initial first pass, helping you identify structural and linguistic problems. Keep decisions that depend on product, organizational, or domain knowledge with the team, including:

• Whether the item is necessary, valuable, or feasible.
• Whether its acceptance criteria reflect relevant domain rules.
• Whether its value statement is accurate.
• How it relates to other backlog items, dependencies, and priorities.

A practical workflow is to use the model for an initial review, have a team member examine the issues it flags, and involve someone with relevant product or domain expertise when validating questions of necessity, feasibility, and intent (Levy et al., 2026).

References