What is backlog refinement? How to keep it short

Refinement according to the Scrum Guide 2020, what the PO prepares, how much to refine, how to split big items and handle items nobody understands, with a pre-read and checklist to use straight away.

Written by Phan Lam Duy Khoi

Backlog refinement is the ongoing work of breaking down and clarifying backlog items, adding description, order and size, with the Developers doing the sizing. To keep it from wasting time, the PO brings only items for the next one or two sprints, sends a pre-read, splits big items, and turns questions nobody can answer into an action with an owner instead of a debate.

Almost two hours of refinement, three items estimated

You are the PO for the ordering app of an online tea shop. This afternoon the team has a refinement session. You share the backlog on screen and work from the top: twelve items, some for the next sprint, some just “one day” ideas.

The first item is “Redo the cart”. The team spends almost forty minutes on it: which part to redo, what it should look like, whether to save the cart when a customer logs out. The second item is “Loyalty points”. A developer asks what ten points can be exchanged for and whether points expire. You do not know. Three people start guessing. By the end, the team has estimated only three items, everyone is tired, and next week's sprint planning will still have unclear items.

This is an illustrative situation. The session did not go badly because the team was lazy or because you are bad at the job. It was slow because three things were missing: a narrow scope, a pre-read, and a way to stop a debate when nobody in the room has the answer. This article covers each one, with templates for your next session.

What is backlog refinement?

The backlog is the ordered list of work the team could do on the product. Each line is a Product Backlog item: a user story, a bug to fix, or a technical task.

The Scrum Guide 2020 defines refinement as breaking down and further defining Product Backlog items into smaller, more precise items. It is an ongoing activity that adds details such as description, order and size (the estimate of effort).

Two points from the Scrum Guide are worth remembering as a new PO:

The Developers do the sizing. Developers here means the people in the Scrum Team who build the product, which can include developers, QA and designers. The Guide says the Developers who will be doing the work are responsible for the sizing. The PO can help them understand and select trade-offs but does not supply the numbers for them.
The PO is accountable for effective Product Backlog management: writing and communicating backlog items, ordering them, and keeping the backlog transparent and understood. The PO can delegate some of this work but remains accountable.

The Guide also says that items the Scrum Team can finish within one sprint are deemed ready for selection at Sprint Planning, and that they usually reach that level of clarity through refinement. In other words, good refinement is what makes sprint planning lighter.

Is refinement a required meeting?

No. Scrum has five events: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Refinement is not on that list. Scrum.org also states plainly that refinement is not a Scrum event but an ongoing activity mentioned in the Scrum Guide.

So the Scrum Guide does not say how long refinement should take, who must attend, or how many times per sprint it happens. Many teams choose a regular refinement session because it is easy to schedule. That is the team's choice, not a Scrum rule. Refinement can also happen in a ten-minute conversation between the PO and a developer, or in comments on a ticket.

If your team wants a number to start from, Mountain Goat Software offers a rule of thumb: about 5 to 10 percent of the effort in each sprint goes to refinement. Treat it as a starting point to adjust, not a requirement. The same source notes there is no consensus on who should attend, and advises keeping the meeting as short as possible.

Why does refinement take so long?

A long refinement session with little to show for it can have many causes. For a new PO, these six are worth checking first.

Too many items. When everything in the backlog is up for discussion, the team spends energy on work that is months away, and the nearest work runs out of time.
The team sees items for the first time in the room. People have to read, understand and think about the approach all at once. Questions that could have been asked earlier appear in the middle of the session.
Discussing the solution before the problem is clear. “Redo the cart” does not say where customers are struggling, so everyone pictures a different version.
Debating what nobody knows. When the answer lives in another department or needs a technical check, more discussion in the room does not make it clearer.
Items that are too big. An item that needs several sprints is hard to estimate, and the discussion goes in circles.
The PO presents like a status report. If only the PO talks, the team has no room to ask questions, and technical risks only surface once the sprint has started.

The common root is that the meeting is doing work that should have been done before it. The fix is not a longer meeting. It is moving work out of the room.

How to run a focused refinement in four steps

Here is one way to run your next refinement. The timings are this article's suggestion; adjust them to your sprint length and the team's rhythm.

Four steps to a focused refinement The PO's main effort goes into steps 1 and 2, before the meeting starts.

Pick the scope: Only items for the next 1 to 2 sprints, in order
Send a pre-read: One or two days ahead, the team asks questions on the ticket
Clarify and split: Answer questions, split big items, Developers estimate
Agree on actions: Unclear items get a question, an owner and a date

Open questions are answered before the next session and go back into the next pre-read.

Steps 1 and 2 make step 3 shorter. When the team has read ahead and asked questions, the PO has time to find answers instead of guessing on the spot. In the meeting, the team only discusses what truly needs several people thinking together.

Step 4 is the one many refinement sessions forget. Every item should leave the meeting in one of four states: clear enough for sprint planning, split into smaller items, holding a specific question with an owner and a date, or moved further down the backlog because it is not needed in the next one or two sprints. No item should leave as “we'll discuss it later”.

What should the PO prepare before refinement?

Preparation does not have to be long. The goal is for the team to walk in knowing what will be discussed and why.

Order the top of the backlog. Know which item matters most and why. If you do not yet have a clear way to order it, the article on prioritising the backlog has concrete steps.
Write the problem before the solution. Each item can be stated in one sentence: who it helps and what it changes. Attach evidence if you have it, such as the number of customer complaints or a screenshot of the bug.
Draft the acceptance criteria (AC). The draft does not need to be perfect. It gives the team something to react to instead of a blank page.
Write down the questions you cannot answer yet. Saying “I don't know this yet” in the pre-read is better than the team discovering it mid-session.
Ask people outside the team first if needed. If an item depends on rules from marketing or finance, ask them before the meeting, or invite them for just that item.
Review open questions from last time. Update the ticket for any question that now has an answer.

One thing is not on the list: the PO does not need to estimate in advance or suggest how many days each item takes. Estimating is the Developers' work.

Prioritising the backlog when everything is urgent

How many items should you refine?

This article suggests focusing on items the team could take on in the next one or two sprints. Mountain Goat Software describes the refinement meeting as making sure the backlog is ready for the next sprint. One more sprint on top gives you a buffer when plans change.

Items further out can stay in the backlog as a one-line description. Detailing them too early easily becomes waste: by the time the work starts, the need may have changed and the detail has to be rewritten.

Do not insist that every item be fully clear either. Mountain Goat Software stresses that questions do not need to be fully resolved in refinement, only enough for the team to feel confident discussing the item at sprint planning. Small details can be clarified during the sprint. Preparing for sprint planning is covered in its own article.

Sprint planning: what the PO prepares

How do you split an item that is too big?

The Scrum Guide treats items the team can finish within one sprint as ready for selection. So when the Developers say an item will not fit in a sprint, that is a signal to split it, not a reason to keep debating how to build it.

Three splitting approaches that work well in a refinement session:

By user path. “Redo the cart” can become: change quantity directly in the cart, save the cart when the customer logs out, suggest add-on items. Each piece is useful to customers on its own.
By data. Start with part of the data, for example only orders from the last thirty days.
By rule. Leave out a complex rule for now and add it in a later item.

Each piece must still deliver something useful to the user. Avoid splitting by technical layer, such as “build the interface” and “build the backend”, because neither piece is usable alone. More splitting approaches are in the article on user stories.

If the room cannot find a way to split it in a few minutes, do not force it. Ask one person, perhaps the PO with a developer, to propose a split before the next session.

How to write a user story for beginners

What do you do with an item nobody understands?

This is where refinement can lose a lot of time. This article's rule: when nobody in the room has the answer, do not debate, pick an action. A simple way is to give each item a time limit, say five to ten minutes, chosen by the team. When time runs out and nothing is clearer, move to choosing an action.

Four actions for an item nobody understands Pick one, write down the owner and the date, then move to the next item.

Ask whoever holds the answer: Business information is missing, such as loyalty rules. The PO asks the relevant team and updates the ticket before the next session.
Time-boxed technical check: Technical information is missing, such as what the payment gateway supports. A developer investigates for a limited time; the output is an answer, not a feature.
Split off the clear part: One part is clear and the rest is not. The clear part can be brought to the next sprint planning; the unclear part becomes its own item.
Move it further down: Nobody needs this in the next one or two sprints. Return it lower in the backlog and revisit it when it nears the top.

When you record the action, write all three parts: the specific question, who will find the answer, and by when. “Look into loyalty points” is not an action. “Ask marketing: what can ten points be exchanged for, do points expire, do cancelled orders earn points. Owner: PO. Answer before the next refinement” is an action.

How does an asynchronous pre-read help?

A pre-read is a note the PO sends before the meeting so the team can read and comment asynchronously, meaning each person does it when it suits them rather than all at once. It helps in three ways:

Questions arrive early. The PO has time to find answers instead of promising “I'll check” mid-session.
Quieter people can contribute. Some people think slowly and carefully, or hesitate to speak in a large meeting. A comment on a ticket gives them that chance.
Some items do not need the meeting. If a small bug is clear and the Developers have estimated it in the comments, the meeting can skip it.

A pre-read only helps if it is short. One page with the list of items, a link to each ticket and what you need from the team is enough. The template below is ready to use.

Example: the same backlog, the next refinement

Back to the tea ordering app from the start. This is an illustrative example of the next refinement, once the PO applies the four steps above.

Two days before the meeting, the PO picks six items for the next two sprints and sends a pre-read: redo the cart, loyalty points, fix the wrong delivery fee display, reorder a past order, notify customers when an order changes status, and e-wallet payments. The team leaves questions on the tickets. The loyalty questions came in before the meeting, but marketing has not replied yet.

An illustrative exchange about the loyalty points item

Dev: What can ten points be exchanged for? Do points expire?
QA: Probably a free cup of tea, like the shop down the road.
PO: I don't have the answer yet; marketing hasn't replied. Let's not guess here. Apart from those two, what else does the team need to know to estimate?
Dev: Whether cancelled orders earn points. That one changes a lot of the logic.
PO: I've written down all three. I'll ask marketing and update the ticket before the next refinement. We won't estimate this one today. Let's move to the delivery fee.

The whole exchange takes a few minutes. The team does not argue about rules nobody in the room can decide. The questions are written clearly, with an owner and a date.

Two refinement sessions of the same team compared (illustrative example)
Area	Previous session	Session after the fix
Items brought in	Twelve items, from next sprint to “one day”	Six items for the next two sprints
Preparation	The team saw items for the first time on screen	Pre-read sent two days ahead, questions asked on tickets
Redo the cart	Almost forty minutes on the interface	Split into three items. Changing quantity in the cart and saving the cart on logout are estimated. Add-on suggestions moved further down
Loyalty points	Three people guessing the rules	Three questions for marketing, PO owns them, due before the next session
E-wallet payments	Not reached	A developer checks the payment gateway within a time limit and reports back
Result	Three items estimated, many still vague	Five items estimated and ready for sprint planning. Every other item has a clear action

The five estimated items are the two cart items split from the original, the delivery fee bug, reordering a past order, and order status notifications. The meeting did not need to be longer. The work moved to before and after the meeting.

Pre-read and per-item checklist templates

These two templates work together. The pre-read goes to the whole team before the meeting. The checklist is for each item, while you prepare and during the session. Copy them and adapt them to how your team works.

Refinement pre-read

REFINEMENT [date]: PRE-READ

Goal of the session: clarify items for [the next sprint / the next two sprints], towards [the nearest product goal].
Expected length: [minutes]

Before the meeting, please:
- Read the items below
- Leave questions on the ticket by [time, date]

Items to discuss (in priority order):
1. [Item name] · [link] · Needed from the team: [estimate / ideas for splitting / technical question]
2. [Item name] · [link] · Needed from the team: [...]
3. [Item name] · [link] · Needed from the team: [...]

Open questions from last time:
- [Question] · Owner: [name] · Status: [answered / not yet]

Not discussed in this session: [out-of-scope items]

After the meeting: the PO updates the tickets and sends the list of actions by [date].

Per-item refinement checklist

Item: [name and link]

[ ] Can be stated in one sentence: who it helps, what it changes
[ ] Has AC clear enough to test, or a draft for the team to comment on
[ ] The Developers think it can be finished within one sprint
    (if not: split by user path, data or rule)
[ ] The Developers have estimated it, or noted what they need to know first
[ ] Dependencies outside the team have someone following them

Open questions:
- Question: [...] · Owner: [...] · Due: [...]

Outcome for this item:
[ ] Clear enough for sprint planning
[ ] Split into: [names of the new items]
[ ] Waiting for answers (see open questions)
[ ] Moved further down the backlog

This checklist is a set of prompting questions for refinement, not an approval gate. An unticked box leads to an action, not to a reason to reject the item. If your team wants a shared readiness checklist, the article on the Definition of Ready and Definition of Done explains how to keep it light.

Definition of Ready and Definition of Done

Signs refinement is wasting time, and how to fix them

The table below helps you spot the problem from what you can see. The causes are only possibilities; ask the team at the retrospective to find the real cause in your team.

Signs of ineffective refinement and how to fix them
Sign	Possible cause	Fix
Long meetings, few items estimated	Too many items, the team sees them for the first time	Bring only items for the next 1 to 2 sprints and send a pre-read
One item is discussed for a very long time	Information is missing that nobody in the room has	Stop, write down the question, the owner and the date
Sprint planning turns into writing requirements	Items for the next sprint were not refined beforehand	Refine the top of the backlog before sprint planning
Estimates differ widely between people	Each person understands the scope differently	Ask the highest and lowest estimators to explain, then clarify the scope or split the item
An item is too big for anyone to estimate	The item has not been split	Split by user path, data or rule
Only the PO talks, the team stays quiet	The session runs like a presentation	Ask open questions and let the team ask questions on the tickets beforehand
Items at the bottom are very detailed but never get built	Refining too far ahead of need	Keep distant items to one line and detail them as they near the top

Beyond the table, there are four mistakes new POs easily make:

Estimating for the team. Offering a number first “to speed things up” can anchor the team to it. Let the Developers estimate while you explain the value and scope.
Turning refinement into an approval gate. If every item must pass every condition, the team slows down. The aim is clear enough to start, not perfectly clear.
Skipping refinement when busy. A busy sprint is when it is easiest to skip, and the next sprint planning pays for it. If you cannot meet, at least send the pre-read and ask for estimates in the comments.
Not sending results after the meeting. Actions that are not written down get forgotten. Send the list of actions right after the session, with owners and dates.

Summary

According to the Scrum Guide 2020, refinement is the ongoing work of breaking down and clarifying backlog items, adding description, order and size. It is not a Scrum event, and the Guide does not set a length.
The Developers do the sizing. The PO is accountable for the backlog: writing items, ordering them, keeping it understood.
Four steps to a focused refinement: scope it to the next 1 to 2 sprints, send a pre-read, clarify and split in the session, agree on actions for unclear items.
Split items that are too big by user path, data or rule, with each piece still useful to the user.
For an item nobody understands, do not debate: pick an action and write down the question, the owner and the date.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

Get new articles by email

Frequently asked questions

Is backlog refinement an event in Scrum?

No. The Scrum Guide 2020 describes refinement as an ongoing activity, not one of the five Scrum events. The team chooses how to do it: a regular session, short conversations, or an asynchronous pre-read with comments.

How long should a backlog refinement session be?

The Scrum Guide 2020 does not set a length for refinement. Mountain Goat Software offers a rule of thumb of about 5 to 10 percent of each sprint's effort on refinement, and advises keeping the meeting as short as possible.

Who estimates backlog items during refinement?

The Developers, meaning the people who will do the work. The PO explains the value, answers questions and helps the team see trade-offs, but does not dictate the estimates.

Sources to check

What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.