Using AI to support backlog refinement: questions before acceptance criteria
A backlog item can sound clear until someone asks what happens at the boundary. Can a user extend a loan on its due date? What if another person reserves the equipment while the extension is being saved?
AI can help surface those questions and prepare examples for discussion. Its contribution is useful when the output makes uncertainty easier to see. A detailed list of acceptance criteria becomes a problem if it quietly invents product rules.
This article starts with an existing item, rather than grouping raw feedback or ranking priorities. You will use a loan-extension example to examine behaviour, check proposed criteria and prepare a focused refinement conversation.
What refinement is trying to improve
In Scrum, Product Backlog refinement involves making items smaller and more precise as understanding develops. The Product Owner remains accountable for effective backlog management, while the Developers doing the work are responsible for sizing. These responsibilities are described in the Scrum Guide.
The AI workflow below is a preparation technique. It is not a new Scrum event, a mandatory readiness gate or a transfer of those responsibilities to software. Its output should help the team discuss behaviour and uncertainty.
Begin with the item and the evidence
For example, consider an internal equipment-loan product. The existing item says: “Let a borrower extend an active loan so they can keep using the device.” The team supplies two notes:
- R1, current service note: “A loan may be extended once if the device has no reservation. The extension adds seven calendar days to the existing due date.”
- R2, stakeholder comment: “Could we allow two extensions for longer projects?”
R1 describes current rules. R2 is a question about changing them. Neither note defines what happens if a reservation is added between the eligibility check and saving the extension, or whether an overdue loan qualifies.
Keep those notes beside the item. If you provide only its short description, the assistant has no basis for knowing the extension limit or the date calculation. More polished wording will not supply that missing authority.
Prepare the discussion in four passes
1. Separate rules from requests
Purpose: Avoid turning a suggestion into agreed policy.
Ask the assistant to identify statements supported by the notes and differences that require a decision. In this example, one extension is supported by R1. Two extensions is a proposal in R2.
A draft saying “borrowers can extend twice” has promoted a question into a rule. Mark the conflict for the Product Owner and relevant stakeholders to resolve, rather than averaging the two statements or choosing the newer-looking one.
2. Ask for behaviour questions
Purpose: Look beyond the successful path.
Ask what the borrower can do, what conditions matter and what could change during the action. Questions could cover overdue loans, already-extended loans, reservations and whether the existing due date remains visible after a failed request.
Include a change-between-steps case. The device has no reservation when the screen loads, but a reservation appears before the borrower saves. That exposes a consistency question a happy-path description can miss. It does not establish the correct implementation.
3. Draft examples with visible status
Purpose: Keep proposed expectations distinct from approved behaviour.
Acceptance examples describe a situation, an action and an expected result. Give each expectation a status: supported by a note, proposed for discussion or unresolved. That prevents an example table looking more agreed than it is.
For a due date of 10 November 2026, adding seven calendar days gives 17 November 2026. That follows R1. Whether the extension is allowed after the original due date remains an unanswered policy question.
4. Bring a short decision list to refinement
Purpose: Use meeting time for the real uncertainties.
Review the AI output before the conversation. Remove duplicates, misleading assumptions and questions already answered by the product. Bring the few gaps that prevent the team understanding the work.
During the discussion, record decisions and their owners. Ask Developers about technical feasibility and sizing. Do not accept AI-generated story points as a substitute for the people doing the work assessing it.
Three examples to inspect
| Situation and action | Expected result and status |
|---|---|
| Active, unextended loan; no reservation; borrower requests an extension | Due date moves from 10 to 17 November 2026. Supported by R1, assuming the loan remains eligible when saved. |
| Loan has already been extended once; borrower requests another extension | R1 allows one extension. The requested second extension needs the R2 policy discussion; its final handling is unresolved if policy changes. |
| No reservation at screen load; a reservation arrives before save | The team must decide how eligibility is checked and what message the borrower receives. Outcome unresolved; do not invent a reservation override. |
The table deliberately leaves some results unfinished. Filling every cell with an invented answer would produce a tidier artefact and a less reliable refinement discussion.
A prompt for reviewing an existing item
Supply the item, its current notes and any approved constraints after this prompt. Use an approved AI application and remove information that is unnecessary for the exercise.
Review this existing backlog item and its supplied source notes. Produce: (1) supported behaviour with source references; (2) conflicting statements; (3) unanswered behaviour questions; (4) draft acceptance examples, with each expected result marked as supported, proposed for discussion or unresolved. Cover the main path, a boundary case and a change between checking and saving. Do not invent policy, user evidence, effort, story points or priority. Do not alter the backlog. Keep sizing with the people doing the work and return questions for a human refinement conversation.
Check what the assistant added
Look for invented limits, notification channels, administrators, automatic approvals and dates. An AI suggestion that the system should send an email might be worth discussing, but neither R1 nor R2 requests one. Label it as an option and decide whether it belongs in scope.
Ask whether the draft acceptance examples accidentally change the definition of completion. Acceptance criteria are item-specific expectations; they do not replace the team’s Definition of Done. In Scrum, that definition expresses the quality measures work must meet to form part of an Increment.
If the item remains too large, use the questions to explore a smaller useful behaviour with the team. Do not split it into isolated technical tasks merely to make the list look shorter. Keep the borrower’s need and the agreed product boundary visible.
Leave with decisions, questions and a next action
A useful refinement note might record that the existing one-extension rule applies to this item, while the two-extension proposal needs separate evaluation. It might also name who will clarify overdue behaviour before the examples can be finalised. Those are possible meeting outcomes, not decisions made by this exercise.
Try the workflow on one existing item with two or three source notes. Count the material unanswered questions it helps you bring to the team, rather than the number of criteria it generates.
Sources checked on 21 October 2026. The worked example and template are original Coded Female teaching material. Product controls vary by application and organisation.
You May Also Like
Removing blockers: a practical guide for Scrum Masters
Understanding Product Risk Taxonomy: Why It Matters and How to Manage It
