Backlog Refinement
A recurring collaborative session where the Product Owner and development team review, clarify, estimate, and prioritise Product Backlog items. Refinement ensures the top of the backlog is always well-understood and 'Ready' — small enough, clear enough, and estimated — before Sprint Planning.
How to run it
- 1
Product Owner presents upcoming backlog items in priority order.
- 2
The team asks clarifying questions until the acceptance criteria are clear and unambiguous.
- 3
Break large items (Epics) into smaller user stories that can be completed within one Sprint.
- 4
Estimate each item using Planning Poker, T-Shirt Sizing, or story points.
- 5
Flag any dependencies, risks, or assumptions that need resolution before the item can be worked on.
- 6
Apply the Definition of Ready: only items meeting the DoR threshold get moved to the 'Ready' column.
- 7
Stop when the top 2 Sprints of backlog are refined — don't over-refine.
Tips
Keep refinement to 10% of team capacity (roughly 4h per 2-week Sprint).
Don't refine more than 2-3 Sprints ahead — requirements change.
If a story triggers more than 15 minutes of discussion, it needs splitting.
The Product Owner should come prepared — vague stories waste the whole team's time.
Variations
Three Amigos: a developer, tester, and Product Owner meet briefly for each story before refinement to pre-align on scope. Async refinement: team comments on stories asynchronously in Jira/Linear before the live session.
Where it fits
Related methods
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Backlog Refinement into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Scrum Guide.