Backlog Refinement
The ongoing process of keeping your product backlog clear, ordered, and ready to plan — so sprint planning stays focused on commitment, not discovery.
What Is Backlog Refinement?
Backlog refinement — sometimes called backlog grooming — is the activity of reviewing, clarifying, ordering, and estimating the items in your product backlog. It is not a one-time event. It is a continuous conversation between the Product Owner and the development team that keeps the backlog healthy and ready for sprint planning.
The Scrum Guide deliberately avoids prescribing a rigid meeting format for refinement. It describes it as an ongoing activity that consumes no more than ten percent of the team's capacity. In practice, most teams block out one or two dedicated sessions per sprint, typically in the middle of the current sprint so that the next sprint's backlog is ready before sprint planning day.
A well-refined backlog is arguably the most important enabler of a healthy sprint rhythm. When items at the top of the backlog are clear, estimated, and small enough to fit in a sprint, planning sessions become quick and confident. When the backlog is a pile of vague epics and half-finished ideas, every sprint planning session turns into a fire drill.
Who Participates
Product Owner (Lead)
The Product Owner drives refinement. They bring the backlog items, explain business context, clarify requirements, and make final decisions on priority order. A PO who does not actively participate in refinement creates a context gap that slows every subsequent ceremony.
Development Team
Developers ask clarifying questions, identify technical unknowns, propose story splits, and provide estimates. The team's involvement ensures that items are refined to a level of technical clarity, not just business clarity. A story that reads well from a product perspective might still be ambiguous from an engineering one.
Scrum Master (Optional Facilitator)
The Scrum Master may facilitate refinement sessions, help keep discussions on track, and coach the team on refining stories effectively. Their presence is not always mandatory — mature teams often run refinement without a dedicated facilitator.
The full team does not always need to attend every refinement session. For very large teams it can be effective to have a subset of engineers join the PO to do initial clarification, with estimates gathered separately via a tool like planning poker.
When to Run Refinement Sessions
Most teams schedule one or two refinement sessions per sprint. A common pattern for two-week sprints is to run refinement in the middle of the sprint — around day five to seven. This timing means items refined this week are ready for sprint planning at the start of next week.
Do not leave refinement until the day before sprint planning. If a story needs significant rework — a dependency that was not discovered, an acceptance criterion that requires design review, a technical spike that needs to happen first — there is no time to address it before it blocks planning.
Some teams prefer a rolling refinement model where a short session (thirty to forty-five minutes) happens on a fixed day each week, rather than one longer session per sprint. This creates a more consistent rhythm and prevents backlog debt from accumulating between sessions.
The “Two Sprint Ready” Rule
Aim to have the top of your backlog refined at least two sprints ahead of the current sprint. This buffer means that even if a refinement session is cancelled or runs short, sprint planning is never blocked by missing clarity.
The INVEST Criteria for Good User Stories
The INVEST acronym is a widely-used checklist for assessing whether a user story is ready to be worked on. Applying it during refinement surfaces problems early, before they become sprint blockers.
ndependent
The story should be deliverable without depending on another unfinished story. Dependencies between stories create sequencing problems that are hard to manage in a sprint. If stories are tightly coupled, they should be merged or sequenced with clear sprint boundaries between them.
egotiable
A story is not a signed contract. The details can and should be discussed and refined. The card represents a conversation, not a specification. If a developer finds a simpler way to achieve the business outcome, they should be empowered to suggest it.
aluable
Every story should deliver tangible value to users or the business. Pure technical tasks can be described in terms of the risk they reduce or the capability they enable. If you cannot articulate the value of a story, reconsider whether it should be in the backlog at all.
stimable
The team should be able to estimate the story with reasonable confidence. If they cannot, the story needs more clarification, or a technical spike is required to reduce the unknowns before the story can be estimated and planned.
mall
Stories should be completable within a single sprint, ideally in two to three days. Large stories (epics) need to be split. A story that takes an entire two-week sprint to complete creates an all-or-nothing delivery risk.
estable
There must be a way to confirm the story is done. Acceptance criteria should describe concrete, verifiable conditions. “The system should be fast” is not testable. “The search results page loads within two seconds for queries returning up to 100 results” is.
Splitting Large Stories
Story splitting is one of the most valuable and most under-practised refinement skills. When teams fail to split large stories, they carry oversized items into sprints, the burndown chart flatlines for days, and the sprint review shows one or two incomplete features rather than a stream of delivered value.
There are several reliable patterns for splitting a large story into smaller, independently deliverable slices:
Split by workflow step. If a feature involves multiple stages — upload, validate, process, notify — each stage can be a separate story with a simpler version of the next stage as a stub.
Split by user role. If multiple types of user interact with the same feature differently, deliver the simplest user's version first. Add complexity for other roles in subsequent stories.
Split by happy path vs. edge cases. Deliver the core happy path first. Error handling, edge cases, and validation can follow as separate stories once the main flow is working.
Split by data type or input type. If a feature handles multiple kinds of input (file types, payment methods, delivery options), implement one type first and add the others incrementally.
Spike first. If the team cannot estimate a story because of technical uncertainty, create a spike — a time-boxed investigation task — to answer the unknowns. The spike produces knowledge, not production code, and is estimated and sized on its own.
Writing Acceptance Criteria
Acceptance criteria are the conditions that must be true for a story to be considered complete. They bridge the gap between the business intent described in a user story and the concrete implementation delivered by the team.
The most popular format is Given / When / Then (Gherkin syntax), which describes a scenario from the user's perspective in terms of preconditions, actions, and expected outcomes. For example:
Given
a registered user who is logged in
When
they submit the checkout form with valid payment details
Then
they see an order confirmation page
and they receive a confirmation email within two minutes
Not every team uses Gherkin syntax, and that is fine. What matters is that acceptance criteria are:
- ✓ Written before development starts, not after
- ✓ Agreed by both the Product Owner and the development team
- ✓ Specific enough to be tested unambiguously
- ✓ Focused on behaviour and outcomes, not implementation details
During refinement, walking through acceptance criteria together is one of the most effective ways to surface hidden assumptions. Disagreements about the criteria almost always point to a deeper misunderstanding about the scope of the story.
Estimating During Refinement
Many teams estimate stories during refinement sessions rather than at sprint planning. This separation has clear advantages: the discussion happens when the story is freshest in everyone's mind, estimates inform priority decisions before the sprint planning meeting, and planning itself stays focused on commitment rather than analysis.
Planning poker is particularly effective for remote refinement estimation. Each team member votes simultaneously on a story's complexity using Fibonacci-based cards, preventing early answers from anchoring everyone else's judgment. When there is a wide spread in votes, the high and low voters explain their thinking — this discussion almost always reveals a misunderstanding about scope or technical complexity that improves the final estimate.
For estimation to work well in refinement, the story must already be clear enough for the team to have an informed opinion. If the discussion about what the story means is still ongoing, estimating it in the same session is premature. In that case, clarify first, then estimate in the next session or asynchronously.
Some teams use T-shirt sizes (S, M, L, XL) for initial sizing in refinement and convert to story points at sprint planning. This two-pass approach works well when the backlog contains many items that need rough ordering before the team invests time in precise estimation.
Definition of Ready: When to Stop Refining
Some teams define a “Definition of Ready” — a checklist of conditions a story must meet before it can be pulled into a sprint. Unlike the Definition of Done (which defines when a story is complete), the Definition of Ready defines when a story is ready to start.
A common Definition of Ready includes:
- ✓ The story has a clear title and description
- ✓ Acceptance criteria are written and agreed by the team and PO
- ✓ The story is estimated in story points
- ✓ The story fits within a single sprint
- ✓ Dependencies are identified and either resolved or planned for
- ✓ Any required design or UX assets are available
The Definition of Ready is a guide, not a bureaucratic gate. Applying it rigidly can create delays for genuinely simple, well-understood items. Apply judgment — a two-point bug fix does not need formal acceptance criteria the way a new user-facing feature does.
Common Backlog Refinement Mistakes
Treating Refinement as Optional
Teams that skip refinement pay the cost at sprint planning — longer sessions, more confusion, and stories that get pulled back because they were not ready. Refinement is not overhead; it is investment in a smoother planning cycle.
Refining Too Far in Advance
Refining stories that are ten or fifteen sprints away is usually wasted effort. Requirements change, priorities shift, and the details you agreed three months ago are often wrong by the time the story reaches the top of the backlog.
PO-Only Refinement
When Product Owners refine stories in isolation and hand them to the team as finished specifications, the team's understanding of the work is shallow. Engineers who helped shape the acceptance criteria own the implementation differently from engineers handed a brief they had no part in writing.
Skipping Story Splitting
Large stories are a sprint risk. They are hard to estimate accurately, hard to test in one pass, and if they are not done at the end of the sprint they contribute nothing to the sprint review. No matter how urgent a large story feels, splitting it into smaller deliverable slices almost always leads to faster overall delivery.
Vague Acceptance Criteria
“The page should look good on mobile” and “performance should be acceptable” are not acceptance criteria — they are sources of disagreement at the sprint review. If the team cannot tell from the criteria alone whether a story is done, the criteria need more specificity.
Start estimating your backlog now.
Planning poker is the fastest way to get calibrated story point estimates from your whole team. Free, instant, no account required.