Scrum guide · Artifacts and practices
Backlog Refinement in Scrum: How to Run It Well
Backlog refinement is the ongoing activity of breaking down and adding detail to Product Backlog items, such as a description, order and size. In Scrum it is not a formal event: it keeps the top of the Product Backlog clear enough for the team to plan Sprints with confidence.
Key takeaways
- Backlog refinement is an ongoing activity, not a formal Scrum event.
- It breaks down items and adds detail such as description, order and size.
- The Product Owner and Developers refine together; the Developers size the work.
- Keep about one to two Sprints' worth of items ready and split them vertically.
What refinement is, and is not
The 2020 Scrum Guide describes Product Backlog refinement as the act of breaking down and further defining items into smaller, more precise items. It is an ongoing activity, so it is not one of the five Scrum events. Many teams still hold a regular refinement session because it makes the work predictable.
| Refinement is | Refinement is not |
|---|---|
| Clarifying what an item means and why it matters | Committing to work for the next Sprint |
| Splitting large items into smaller ones | Assigning tasks to individuals |
| Sizing items so they can be ordered and forecast | Detailed technical design of every item |
| Adding acceptance criteria | A status meeting |
| Ongoing and collaborative | Something the Product Owner does alone |
Who takes part
- Product Owner: brings context, explains the value of items and accepts trade-offs. Accountable for the backlog.
- Developers: ask questions, suggest splits and simpler options, and size the items. The Scrum Guide makes them responsible for sizing.
- Scrum Master: helps when needed, for example by coaching the team on splitting techniques or keeping sessions focused.
- Stakeholders and experts: invited when an item needs their knowledge, such as a customer, designer or compliance specialist.
How much time to spend
The 2020 Scrum Guide does not set a time limit for refinement. Earlier versions suggested it usually takes no more than 10% of the Developers' capacity, and many teams still use that as a rough guide. In a two-week Sprint, that is often one or two sessions of an hour or so, plus informal conversations.
How to run a refinement session
- Prepare. The Product Owner picks the items near the top of the backlog that need attention and shares them in advance.
- Explain the why. For each item, the Product Owner describes the problem, the user and the outcome wanted.
- Ask and answer questions. Developers explore edge cases, dependencies and risks. Note open questions and who will answer them.
- Agree acceptance criteria. Write down the conditions that will show the item works.
- Split if needed. If an item could not be Done within one Sprint, split it into thinner slices that still deliver value.
- Size. Developers estimate, for example with story points and Planning Poker.
- Re-order. The Product Owner adjusts the order based on what has been learned.
- Close. Confirm which items are ready for Sprint Planning and what follow-ups are needed.
Ways to split large items
| Technique | Example |
|---|---|
| By workflow step | "Checkout" becomes basket review, delivery details and payment |
| By business rule | Support standard delivery first, express delivery later |
| By data or input type | Accept card payments first, then digital wallets |
| By user or role | Customers first, then administrators |
| Simple first, then improve | Basic search, then filters, then saved searches |
| Spike first | A time-boxed investigation before estimating an uncertain item |
Split vertically, so each slice is usable on its own, rather than horizontally into layers such as database, interface and testing. See epics vs stories vs tasks.
Worked example
A team refines the item "Customers can track their order", which the Developers think is about 20 points, too big for a Sprint where they usually complete around 25 points alongside other work. After discussion they split it:
| New item | Acceptance criteria (summary) | Size |
|---|---|---|
| Show order status on the account page | Status shows placed, packed, shipped or delivered | 5 |
| Email when an order ships | Email sent within 10 minutes, with tracking link | 3 |
| Show courier tracking in the account page | Live tracking from the courier's API | 8 |
| Spike: courier API limits | Answer: can we poll every 15 minutes? | 2 |
The total is 18 points, and each item is usable on its own. The Product Owner orders the status page and email first, because they deliver most of the value, with the spike next so that the tracking item is lower risk when it reaches the top.
Tips and common mistakes
- Refine continuously, not only in a rush the day before Sprint Planning.
- Keep sessions short and focused on the top of the backlog.
- Bring the whole team, or at least the Developers likely to do the work; sizing by one person loses shared understanding.
- Don't over-specify: leave room for conversation during the Sprint.
- Use a lightweight checklist, sometimes called a Definition of Ready, if it helps, but don't turn it into a gate that blocks useful work.
- Track open questions visibly so they are answered before Sprint Planning.
Free templates for this topic
Frequently asked questions
What is backlog refinement in Scrum?
It is the ongoing activity of breaking down and adding detail to Product Backlog items, such as description, order and size, so they are ready for Sprint Planning.
Is backlog refinement a Scrum event?
No. The 2020 Scrum Guide describes it as an ongoing activity, not one of the five events. Teams can still schedule regular refinement sessions.
Is backlog refinement the same as backlog grooming?
Yes. Grooming is the older term; refinement replaced it in the Scrum Guide and is now the standard name.
Who attends backlog refinement?
The Product Owner and the Developers, with the Scrum Master helping where useful. Stakeholders or experts join when an item needs their input.
How long should backlog refinement take?
The 2020 Scrum Guide sets no limit. Earlier versions suggested no more than about 10% of the Developers' capacity, which is still a common guide.
How often should we refine the backlog?
Continuously. Many teams hold one or two short sessions per Sprint and handle smaller questions as they arise.
Who estimates during backlog refinement?
The Developers who will do the work. The Product Owner explains the items and trade-offs but does not set the estimates.
What is the difference between backlog refinement and Sprint Planning?
Refinement prepares items over time. Sprint Planning is a time-boxed event where the team sets the Sprint Goal, selects items and plans the work.
What does ready mean in backlog refinement?
The Scrum Guide says items that can be Done within one Sprint are deemed ready for selection in Sprint Planning. Some teams add an optional Definition of Ready.
How far ahead should we refine the backlog?
Usually enough for the next one or two Sprints. Refining far ahead risks waste because priorities and understanding change.
Can backlog refinement happen during the Sprint?
Yes. It happens throughout the Sprint, alongside the work on the current Sprint Backlog.
What if backlog refinement sessions keep overrunning?
Prepare items in advance, focus on the top of the backlog, time-box each item and move deep technical questions to a smaller follow-up or spike.