What Is Backlog Refinement?

In Scrum, Backlog Refinement is an ongoing process in which the Product Owner and the Development Team collaborate to ensure that items on the Product Backlog.

• are understood the same way by all involved (shared understanding),

• have a size estimate for the (relative) complexity and effort of their implementation, and

• are ordered according to their priority in terms of business value and effort required.

In short: Backlog Refinement is about creating a shared understanding of what the Product will, and won’t, do, the effort, it will take to implement it, and the order in which you’ll do that.

Why Is Backlog Refinement Important?

Let’s inspect the goals of Backlog Refinement from the previous section.

• Without shared understanding, you risk implementing the wrong thing, wasting effort, and having to rework the implementation to get it right.

• Without sizing each item, you’re not taking the ‘cost’ of items into account and risk overrating high-value, high-cost items, and underrating lower value, lower-cost items.

• Without ordering your Product Backlog in descending order of prioritization, you risk working on items that aren’t all that important and missing important ones.

A few other reasons why backlog refinement is important:

• It improves the efficiency of the Sprint Planning meeting because most questions are already answered.

• It keeps the Product Backlog focused, clean, and relevant, so you won’t feel like you’re drowning in an ever-growing to-do list.

• It leverages the benefits of collaboration in detailing user stories and defects.

• It creates a shared understanding within the Scrum Team and the stakeholders around it.

What’s the Difference With Backlog Grooming?

There’s no difference. Backlog refinement used to be called backlog grooming. It changed because grooming became a dirty word.

It’s also called storytime, pre-planning, and backlog management.

When’s the Best Time for Backlog Refinement?

There’s no best time.

Backlog refinement is an ongoing activity. Not just for the Product Manager, but for the entire team.

The Product Owner can refine items on the backlog at any time, in or outside a meeting. The Scrum Master and Development Team Members can also update items at any time. Usually under the direction of the Product Owner.

What Happens in Backlog Refinement?

Activities in Backlog Refinement

Backlog refinement is about creating a shared understanding of what the Product will, and won’t, do and what it will take to create it.

• Product Discovery, both initially, for example through Story Mapping, and on an ongoing basis.

• Identifying and removing items that sounded good but are no longer relevant.

• Improving clarity and preventing misunderstanding by adding details in preparation for implementation. For example adding examples, constraints, edge cases, and acceptance criteria.

• Splitting large items into smaller ones. Smaller items are more focused and manageable and are easier to size.

• Sizing items, including re-sizing them

  • when they’ve sat in the Product Backlog longer than intended.

  • as a sanity check when they’re up for implementation.

• Prioritizing items, and re-prioritizing them when you add more details or gain new insights.

• Identifying risks and obstacles for items close to implementation.

The outcome of these activities should be a Product Backlog that’s DEEP. An acronym coined by Roman Pichler:

• Detailed appropriately. More detail for items that you’ll implement soon. Of course, when detailing your user stories, you’ll want to keep the INVEST criteria in mind (see User Stories.)

• Emergent. You can reflect new insights easily by adding, changing, and removing items.

• Estimated. Every item is roughly estimated, or size. And re-sized for new information and as an item gets closer to implementation.

• Prioritized.

Keeping the backlog DEEP, ensures that items with the highest priority, the ones at the top of the Product Backlog, have a refinement level that’s ready for implementation.

Items with a lower priority, the ones further down, can and should have less effort invested in them and have fewer details. That’s part of how you maximize the work not done.

Invest in a Definition of Ready

Similar to a Definition of Done, a Definition of Ready helps you to detail user stories to a consistent level. It specifies what a user story needs to include before you’ll accept it for implementation in a Sprint. For example:

• The objective of the item – how it will help a customer or user do their jobs.

• The business value it’ll provide (by the Product Owner).

• An estimate of the complexity and effort required  (by the Development Team).

How Long Should Backlog Refinement Take?

The Scrum Guide doesn’t say anything about how much time Backlog Refinement should take. It only specifies that it usually does not take more than 10% of the capacity of the Development Team.

The Product Owner isn’t part of the Development Team and can invest as much time as necessary and can enlist the help of other members of the Scrum Team.

Turning a story into a Spike is a way to make this explicit and keep it from eating into that 10%.

Backlog Refinement Meetings

When’s the Best Time for a Backlog Refinement Meeting?

There’s no best time.

Keep in mind that Backlog Refinement is an ongoing activity, not a meeting.

Still, many teams like to use a meeting to quickly size user stories. An initial sizing for new stories, or a re-sizing for stories that have been refined since they were added. There is no best time for these sizing meetings either.

• Some teams like to do it early in a Sprint when the insights from inspection (Sprint Review) and retrospection (Retrospective) are still fresh.

• Others prefer it at the end, so the refinement discussions are still fresh when they plan the next iteration.

• And still, others do it mid-iteration and alternate the Backlog Refinement and Sprint Planning meetings.

If you think you shouldn’t do it near the end of a Sprint, you’re probably cutting refinement too close. You really should have at least 2 or 3 Sprints’ worth of fully refined items. That also ensures you have ample time to answer any questions.

Who Attends a Backlog Refinement Meeting?

The Product Owner always participates. Who else attends can vary with the items that are up for refinement.

Potential participants are

• Members of the Development Team

• Representatives from Customer Success or Support 

• Other stakeholders from the business

• Members of the QA team (if you still have separate development and QA teams)

The Scrum Master is not needed in the meeting but is important in helping the rest of the team understand what makes a good Product Backlog item and how you prioritize them to maximize the value delivered.

Who Facilitates a Backlog Refinement Meeting?

Quite often, it’ll be the Product Owner.

Though logical, it carries the disadvantage that the Product Owner has a high stake in the direction and outcome of discussions.

Getting the Scrum Master to facilitate is a step in the right direction, as s/he has no official role in the meeting and can be more objective.

The best choice for a facilitator, though, is someone without a stake in the outcome and with excellent facilitation skills. Someone that can hold space for everyone, ensure everyone feels heard, and discussions don’t run in circles.