AI-assisted backlog refinement: let the assistant critique, not write

21 October 2026 · 6 min read

Ask an AI assistant to "write the user stories for search" and you'll get ten tidy, confident stories that could belong to any product. Ask it to pick holes in the three stories your team already wrote, and you'll get the questions that would otherwise surface in the middle of the sprint. The assistant is a much better critic than author. Here is how to use it that way in backlog refinement, without letting it do the team's thinking.

Where AI adds real value in refinement

• Finding the edge cases. Empty states, the second currency, the user with no permission, the import that is ten times bigger than usual. An assistant lists these tirelessly, and a list is quick for the team to cross out.
• Naming the assumptions. "This assumes the user is already signed in" or "this assumes the old export still exists" is worth saying out loud before anyone estimates.
• Checking acceptance criteria. Which criteria can't be tested as written, which ones contradict each other, and which behaviour the story implies but never states.
• Spotting risks and dependencies. Another team's API, a migration, a feature flag, a legal review. The assistant won't know your organisation, but it will ask.
• Splitting a big story. Given a split pattern, by workflow step, by data variation, by happy path first, it proposes slices the team can react to in a minute.

What these have in common: the team supplies the substance, and the assistant reviews it. The output is a list of questions and suggestions, not a finished artefact.

A practical workflow

1. The product owner drafts the stories, briefly. Ten minutes, before the session: a title, the goal in a sentence, and the acceptance criteria that are already known. A rough draft is fine; it has to be yours.
2. Run each story past the assistant. Give it the draft and the context it needs (see the prompts below), and ask for edge cases, assumptions, missing criteria and risks. Do this before the meeting, or live on the shared screen, one story at a time.
3. The team reviews the output together. Read the list out and sort it: keep, drop, or "needs an answer". Kept items become acceptance criteria. Open questions get an owner. Most of the value is in the five minutes of argument about which items matter.
4. Then estimate, with the fuller picture. Vote in secret on the refined story, reveal together, and talk about the spread. A story that went through steps 2 and 3 tends to produce a narrower spread, because the surprises were discussed first. If you want a refresher on what the numbers mean, see story points: complexity and capacity.

Prompts that actually work

The quality of the answer follows the context you give. A generic prompt gets a generic list. The fix is nearly always to say more about your product and your constraints:

Pasting in a schema, an API description or the related stories turns "consider performance" into "the search filters on a column without an index". If your assistant can read your tracker directly, through the Model Context Protocol (MCP), it can gather that context itself, but check what it pulled in before trusting the answer.

The pitfalls to watch for

• Plausible but wrong. The assistant will state a constraint about your system that sounds right and isn't. Treat every claim about your own product as a question to check.
• False completeness. A long, well-formatted list feels exhaustive. It isn't: it misses the things only your team knows, such as the half-finished migration or the customer with a special contract.
• Stories that all read alike. If the assistant writes the stories, they drift towards the same shape and the same generic criteria, and the reason a story matters to your users gets lost.
• Losing the skill. Splitting a story well is a skill people learn by doing it. If the assistant always proposes the split, newer team members never learn to see one. Let someone try first, then compare.
• Anchoring the estimate. If the assistant's output includes a size, everyone who read it is anchored before the vote. Leave sizes out of the prompt and the answer.

When to skip AI entirely

• Small, well-understood changes. A copy fix, a colour change, a bug with a clear reproduction. Reading the assistant's output takes longer than the refinement.
• Plain CRUD on a familiar model. The team has done ten of these; the edge cases are known.
• Sensitive stories. Security fixes, personal data, unannounced features. Use only what your organisation allows you to share with an assistant.
• When the team is learning the domain. The conversation is the point. Let the questions come from people first.

Common questions

Should the product owner or the team run the assistant?

Either, as long as the output is reviewed by the team together. A product owner running it before the session saves meeting time; running it live on a shared screen makes the review natural.

Does this replace the refinement meeting?

No. It makes the meeting shorter and better prepared. The decisions, which questions matter and what the story really is, still happen between people.

Can the assistant estimate after refinement?

It can, but its number shouldn't be the first one the team sees. Vote first and use the assistant afterwards to explain a wide spread, as we describe in AI sprint planning.

What if the team disagrees with the assistant?

The team wins. The assistant's list is a set of suggestions; dropping most of it is a normal outcome. A wide spread after the reveal is the useful kind of disagreement. Here's how to read it.

Where Estimay fits

Estimay is where step 4 happens. Add the refined stories to a room, by hand, from a CSV, or from Jira, Linear, Trello or Asana, then everyone votes in secret and the cards turn over together. The assistant helps the team see the story clearly; the room keeps the estimate the team's own.

← All articles