Backlog refinement that produces estimable stories

What refinement is for

Refinement has one output: a small number of stories the team understands well enough to size and start. Not a design, not a solution document, not a decision about the quarter's priorities. When a session tries to do all four, it produces none of them.

A definition of ready you can actually apply

Write it down once and use it as a gate. A story is ready when:

• The user and the outcome are named — who wants this, and what changes for them.
• Acceptance criteria exist and are testable, including the obvious failure cases.
• Dependencies are identified, and any external decision has an owner and a date.
• It plausibly fits in one sprint. If it obviously does not, it needs splitting first.
• The team has no open question that would change the approach.

A story failing any of these gets parked with a named owner, not a number. Two parked items per session is a healthy sign; zero usually means the team is guessing politely.

An agenda for one hour

1. 0–5 min. Product owner states the goal of the next sprint in one sentence. Everything else is judged against it.
2. 5–15 min. Walk the candidate list, in priority order. Drop anything obviously not ready before spending the room's attention on it.
3. 15–50 min. Per story: read, clarify, split if needed, agree acceptance criteria, then size it. Six to eight stories is a realistic target.
4. 50–60 min. Read back the sized stories, the parked ones and their owners, and the total points against the team's usual range.

Refine roughly one and a half sprints of work — enough that the next sprint planning is uneventful, not so much that you refine items whose priority will change.

Splitting stories that are too big

Splitting is the highest-value skill in refinement, and it is mostly pattern recognition. Useful cuts, in rough order of how often they work:

• By workflow step. Create, then edit, then delete. Ship the first step and learn from it.
• Happy path first. The main case as one story; error handling, validation and edge cases as the next.
• By data variation. One currency, one file format, one country to start with — the rest follow once the shape is proven.
• By interface. API and data model separately from the screen that uses it, when the two are genuinely independent.
• Manual before automatic. Someone does it by hand this sprint; automate when the volume justifies it.
• Spike then build. When the estimate is dominated by unknowns, time-box a small investigation and re-estimate afterwards.

Never split into layers that cannot be released alone ("backend part", "frontend part") if neither delivers observable value — you get two stories and no feedback.

Who should be in the room

Five to eight people, and every one of them either has knowledge the room needs or work to do. Typically: the product owner, the engineers who will build it, someone testing, and design when the story touches the interface. Beyond that, attendance becomes an audience, and audiences make sessions longer and quieter.

Specialists you need for two stories should be invited for the part that concerns them, not for the hour. Anyone joining briefly should be able to participate immediately — no account, no setup.

Common failure modes

• Design in disguise. Twenty minutes on database schema is a design meeting. Note it and schedule it.
• Refining everything. Detailing items three sprints out wastes the effort when priorities move.
• The product owner narrating. If engineers are silent, they are not building shared understanding — ask each of them a direct question.
• No written outcome. Verbal agreement evaporates. Acceptance criteria and the agreed size go in the tracker during the session.
• Estimating to fill the sprint. Sizes chosen to make the total look right corrupt every forecast that follows.

Handing off cleanly to estimation

The smoothest sessions treat refinement and sizing as one continuous pass: a queue of candidate stories, taken in order, each one clarified and then voted on before moving to the next. That keeps context loaded and avoids re-reading every story twice.

Planner Poker is built around that flow: an ordered task playlist you can reorder by dragging, imported directly from your active Jira sprint or typed in as you go, with each item becoming the active story in turn, a hidden vote, an immediate spread, and an agreed value recorded before the queue advances.