Backlog refinement: a practical guide

Backlog refinement is the ongoing work of turning rough items near the top of the product backlog into clear, small, estimated pieces of work that the team could start in the next sprint or two. The product owner and the people who will do the work talk each item through, sharpen its acceptance criteria, split anything too big and agree a size.

Scrum sets no timebox for refinement, but a common rhythm is a session of 45 to 90 minutes once or twice a sprint, with some preparation in between. Done well, it makes sprint planning short and calm. This guide covers what the Scrum Guide says, how often to refine, who should be there, an agenda you can copy, how estimating fits in, and the signs that you are refining too little or too much.

What is backlog refinement?

The Scrum Guide describes refinement in its section on the product backlog:

“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.” The Scrum Guide (2020)

Three words in that definition do a lot of work. Ongoing means refinement is a continuous activity, not a single meeting. Smaller means splitting is part of the job, not an optional extra. And order means a good session leaves the backlog better sequenced as well as better described.

The guide also explains why it matters. Items that can be Done within one sprint are “deemed ready for selection in a Sprint Planning event”, and they “usually acquire this degree of transparency after refining activities”. Refinement is how work becomes ready, so a team that skips it ends up doing it in a hurry during sprint planning.

You may still hear it called backlog grooming. The Scrum Guide introduced the practice under that name in 2011 and renamed it refinement in 2013. The activity is the same.

How often should you refine, and for how long?

The 2020 Scrum Guide gives no timebox, because refinement is an activity rather than one of the Scrum events. It says only that during the sprint “the Product Backlog is refined as needed”. The 2017 edition was more specific: “Refinement usually consumes no more than 10% of the capacity of the Development Team.” That sentence was dropped in 2020, but it still works as a sensible ceiling.

In a two-week sprint, 10% is about one day per person. Few teams need all of it. These rhythms all work in practice:

• One 60-minute session a week. Predictable, easy to protect in calendars and a good default for two-week sprints.
• Two 45-minute sessions a sprint. Gives the product owner time between sessions to chase answers, and suits teams that lose focus in long meetings.
• Short, frequent sessions of 20 to 30 minutes. Good for a fast-moving backlog, as long as they don’t become an excuse to skip preparation.
• A longer workshop when a big piece of work arrives. Spend two hours mapping and splitting a new epic, then return to the normal rhythm.

Judge your rhythm by its results rather than the calendar. A good target is one to two sprints of ready work at the top of the backlog. With less, sprint planning turns into refinement; with much more, the detail goes stale before anyone builds it.

Who should attend backlog refinement?

The Scrum Guide is clear on one point: “The Developers who will be doing the work are responsible for the sizing.” So the people who will build and test the items need to be in the conversation. A lead who estimates on everyone’s behalf misses exactly the knowledge that makes estimates useful.

• The product owner brings the items, explains the problem each one solves and answers questions about value and priority. They can shape the size by trading scope, but they usually don’t vote.
• The developers, which in Scrum means everyone doing the work (engineers, testers, designers, analysts), ask questions, spot risks and agree the size.
• A facilitator, often the Scrum master, keeps time and makes sure quieter people are heard. Once the team runs refinement well on its own, this becomes optional.
• Specialists by invitation, such as a security engineer or someone from the team that owns an API you depend on. Invite them for the items that need them, not the whole session.

Larger teams sometimes ask a small group, often a product person, a developer and a tester, to do a first pass on new items. Some teams call this a “three amigos” session. It works well, provided the whole team still reviews the items and the people doing the work still size them.

A backlog refinement agenda you can copy

Preparation is half of a good session. Before each one, the product owner picks the next 5 to 10 items in order, writes a sentence on the problem each one solves, drafts acceptance criteria and lists open questions. Sharing that list a day ahead lets people arrive with questions instead of first reactions.

Here is an agenda for a 60-minute session:

1. Set the focus (5 minutes). The product owner recaps the product goal and what the next sprint or two is likely to aim for, so everyone knows why these items matter now.
2. Close last time’s questions (5 minutes). Share the answers people went away to find: the reply from legal, the result of a spike, the rate limits on a supplier’s API.
3. Refine items in order (35 minutes). For each item, the product owner explains it, the team asks questions, acceptance criteria are tightened, anything too big is split and the team estimates. Around 5 minutes an item is a healthy pace.
4. Look further ahead (10 minutes). Scan the next items for anything big or risky that needs a spike, a design or another team’s input before it can be refined.
5. Record and confirm (5 minutes). Note who owns each open question, adjust the order if the discussion changed it, and check how many sprints of ready work you now have.

Tip Put a timer on each item. If a discussion passes 10 minutes, the item usually needs a split, a spike or an answer from someone who isn’t in the room. Write the question down, give it an owner and move on.

What to do with items you can’t refine yet

Some items resist refinement. That is useful information, as long as you act on it instead of discussing the same item every week. Most stuck items fall into one of four groups:

• Too vague. Nobody can say what “improve the reporting” means. Ask the product owner to come back with the user, the problem and an example, and leave the item unestimated until then.
• Too uncertain to estimate. The team doesn’t know whether the payment provider supports partial refunds. Plan a short, timeboxed spike with a clear question, then refine the item with the answer.
• Too big. “Customers can manage subscriptions” is an epic, not a story. Split it into thin slices that each deliver something usable; our guide to splitting user stories has ten patterns and a worked example.
• Blocked by someone else. The item needs a change from another team or a supplier. Raise the dependency now, agree a date and note it on the item, so it doesn’t surprise you in sprint planning.

Keep the backlog DEEP

A handy test for the health of the whole backlog is DEEP, an acronym used by Roman Pichler and Mike Cohn. A good product backlog is:

• Detailed appropriately. Items near the top are clear enough to build. Items further down stay rough on purpose.
• Estimated. Everything has a size, but precision falls away lower down: a 3 near the top, a 40 or an L for something months away.
• Emergent. The backlog changes as you learn. Items appear, get rewritten and get deleted.
• Prioritised. Items are in order, most valuable first. The Scrum Guide calls the backlog “ordered”, which is stricter: only one item can be first.

In practice, a DEEP backlog has three bands of detail:

Refinement moves items up through those bands as they approach the top. The common mistake is trying to give everything the top level of detail at once, which wastes effort on items that will change or disappear.

How estimation fits into refinement

Refinement is the natural place to estimate. The people who will do the work are present, the item has just been discussed, and nobody is under pressure to fill a sprint. Leaving estimates to sprint planning makes planning long and rushes the conversation that matters most.

Planning poker suits refinement because its real value is the discussion it triggers. When one person votes 3 and another votes 13, they usually understand the item differently: one has spotted a data migration, or the other knows a library that does most of the work. Talking that gap through is refinement. If the technique is new to your team, start with our guide to planning poker.

A few estimating habits make sessions faster:

• Agree a size ceiling. Many teams split anything above 8 or 13 points before it goes near a sprint.
• Read the “?” votes. Several people saying “not sure” means the item isn’t ready. Capture what is missing as a question instead of forcing a number.
• Size roughly further down. For a long backlog or a new epic, affinity estimation sizes dozens of items in one sitting, leaving planning poker for the items you will build soon.
• Re-estimate only when understanding changes. New information is a good reason to vote again. A bad sprint is not.
• Vote before the meeting when time zones bite. With async planning poker, people vote and comment in their own time, and the live session covers only the items where votes disagree.

On planningpoker.org Anyone can start a free guest session for refinement, for up to 8 people, without an account. Signing in with a free Laya account keeps your sessions in a team workspace and adds Laya boards and Async Poker. With a Jira connection, you can also pick issues from a Jira board and save each agreed estimate back with Save & Next.

Signs you are refining too little, or too much

Signs of too little refinement

• Sprint planning regularly overruns because the team is reading items for the first time.
• Items enter the sprint without acceptance criteria, and developers stop mid-sprint to ask what “done” looks like.
• Votes spread widely (a 2 and a 21 on the same item), or several people play “?”.
• Stories often carry over because they turned out much bigger than anyone thought.
• Nobody can say what the team will probably work on two sprints from now.

Signs of too much refinement

• Detailed stories wait in the backlog for months, then get rewritten or deleted before anyone builds them.
• Refinement regularly takes more than the old 10% guide, which is about a day per person in a two-week sprint.
• The same item comes back session after session without a decision.
• Refinement turns into technical design, and items leave it with implementation plans rather than shared understanding.
• You have four or more sprints of ready work, and it goes stale as the product changes.

Both problems have the same cure: refine just enough, just in time. If the team keeps disagreeing about what “enough” means, write it down as a short Definition of Ready, and keep it a guide rather than a gate. When refinement is healthy, sprint planning becomes a conversation about the sprint goal instead of a reading session.