What Is Product Backlog Refinement?

Refinement is part of working with a product backlog. Refinement is defined in the Scrum Guide as an "ongoing activity to add details, such as description, order, and size." Even though this definition is simple, it can cause a good amount of confusion. 

"Is this the fifth scrum event?", "Don't we do this in sprint 0?", "Isn't that what sprint planning is for?", "We already have the requirements documents; why refine?"

What Is Refinement?

The use of a metaphor helps gain clarity here. Let’s look at a sprint as a Value-Creating Machine. A Sprint Machine.

• The sprint is a value-creating machine: Raw material goes in, and the finished product comes out.
• The scrum team is the engine: The engine makes the sprint machine run. 
• The product backlog is the gas tank: An engine needs fuel to run, or it will not start. So you need something to hold that fuel.
• Product backlog items are the gas in the tank: No gas, no value.

With this metaphor in place, we can ask, "Where does the gas come from?"

"Oh, that's simple, Joel. It comes from the gas station."

Right, and where does the gas station get gas? Is that the source? How many steps are there before the gas gets to the station? 

Can we cut out all this annoying middle stuff?

Last time I checked, I can't pull my F150 up to an oil well in Texas and run a hose to it. Well, I can try, and I won't be very successful making my truck start after that. What comes out of the ground is crude oil. For that crude oil to be usable, it must be… Refined.

And that is what product backlog refinement is: taking big ideas, big effort, and unclear needs and refining them into work that can be taken on by a scrum team and turned into usable increments of value every sprint. Very much like the process of getting crude oil out of the ground, and making it usable, so that your car can run.

A Note on "Grooming": In the early days of scrum, the word grooming was used interchangeably with refinement. We've gotten away from using this word for many reasons. One practical one is grooming does not accurately describe what happens.

Grooming activities like washing, brushing, or braiding your hair are all "simple" activities with a clear how-to and a consistent outcome. However, refining fuel is a complex process that varies depending on the oil you start with and what kind of gas you want.

Getting product backlog items ready for a sprint is complex work. Let's acknowledge that and use the language Ken Schwaber and Jeff Sutherland have used in every edition of the Scrum Guide, product backlog refinement. 

In short, product backlog refinement is taking a backlog item and ensuring the scrum team can complete it in a sprint, thereby creating a usable increment of value.

Why Do You Refine?

With a solid understanding of "What" refinement is, let's step beyond the metaphor to answer some of the "Why?" questions.

Why should you use ongoing refinement instead of the traditional big-requirements-upfront process?

Requirements Go Stale: When my wife and I bought our house, the previous owner had left behind a 50-gallon drum of diesel from their Y2K emergency preparation. 

You might think: “Wow! Fifty gallons would run the tractor for several years. Score!!!”

Yeah, no…

Gasoline doesn't stay good forever. This drum had been in a storage shed for 15 years. Instead of a score, we had to dispose of 50 gallons of hazardous material.

The same applies to traditional requirements documents. In the 90s, I spent months perfecting requirements for a new product. By the time we built the product, so much had changed in the market that much of what I'd written was irrelevant or needed significant updates.

Today, it's not just technology that is changing every three months. The entire world literally changed between February 2020 and March 2020. The idea of "Just in Time" requirements isn't just a good idea anymore; it's almost a necessity.

Why isn't this just part of sprint planning?

There is always a next sprint: Remember the scrum value of Focus. Sprint planning is focused on the work for the current sprint goal. Anything not supporting the sprint goal is not in focus.

Sprint planning is also more than creating a sprint goal (The Why) and deciding what product backlog item (PBI) will be worked on (The What). It is also about creating the plan for creating those PBIs (The How). The team needs time to do The How in sprint planning. For more information about what should be accomplished during sprint planning, see my article on Effective Sprint Planning.

Product backlog refinement is an ongoing activity that paves the wave for future sprints. You want to avoid starving the team and give the product owner breathing room in case something comes up that prevents refinement, such as vacations, stakeholder meetings, illness, etc.

When it comes to how much is enough refined work, I advise targeting 1.5 to 2 times the scrum team's current sprint capacity. If the team averages 10 product backlog items per sprint, having 15 to 20 PBI ready is a good target.

Note: Be cautious of too much ready work. Remember, gas goes stale. I suggest limiting ready work to less than three times your sprint capacity (less than 30 using the above example). 

Why isn't refinement something the product owner does on their own?

The product owner spends a good third of their time working solo on the product backlog (and everything that leads into the creation of it, such as the product goal). Owning the product backlog is one of their key accountabilities. And that one third solo time is not enough. A suitable product backlog item needs…

Alignment: Everyone needs to be on the same page regarding the Why and the What. This alignment comes in three flavors:

• Stakeholder to Scrum Team: "Wow, that looks incredible, but it's not what I wanted" has been heard on far too many traditional development projects. Involving your stakeholders in refinement can lead to work being the correct value the first time.

• Product Owner to Developers: "If I'd known that six months ago, I would have coded that completely differently," said the developer when the product owner revealed a new idea in sprint planning. Context matters and refinement activities can give the developers the context that allows them to create better solutions than if they are just told, "make a blue button."

• Developers to Developers: "Our tech lead meets with the PO for refinement; that's good enough for us." The purpose of a sprint is to create increments of usable value. While a database table is usable, it is not valuable. The same applies to the slick login screen that doesn't talk to anything. Scrum teams are cross-functional so that they can create both usable and valuable work. If all the developers are not in alignment, you could end up with an incomplete or unusable increment at the end of the sprint. Refinement is also about ensuring all the developers are on the same page with what is being created.

How Do You Refine?

Let's start answering this question by first dispelling the myth that product backlog refinement is an event in scrum. There are five events in scrum, the sprint (the container event), sprint planning, the daily scrum, sprint review, and sprint retrospective.

What is an Event?: I like to define events as having:

• A maximum time box: All events have a maximum time box duration.
• A specific cadence: They occur at a specific time and sequence in the sprint.
• Clear attendance: Who is required and optional to attend is clearly documented. 
• Clear outcome: Each event has a clear goal.

The only thing product backlog refinement shares in common with the formal scrum events is a clear outcome. Refinement has no set time box, cadence, or attendance.

Tips for effective product backlog refinement:

These are my tips and tricks for improving your product backlog through refinement.

Focus on the Goal: If I put unleaded gas in my diesel tractor, bad things will happen. Whether it is the best refined super-unleaded or the cheap stuff, my tractor will stop working. Likewise, if the items in your product backlog don't support your product goal, you might build beautifully executed work that doesn't provide value.

The product goal is like the little label on the gas cap that says what type of fuel to use. For example: If your product goal is to revamp your online calendaring application completely, a product backlog item for creating a new instant messenger application has no business being refined.

Ask the Right Questions: The exact questions you will want to ask will vary a lot depending on the work domain. These five questions are good starting points for any PBI being refined.

• What is the desired outcome? What will you be able to do when this PBI is done? 
• Who is this for? Who is going to use the value created by this PBI? Be specific.
• What value will this create? What kind of value will we get from this PBI? Check out my Defining Value in Agile article for more on this.
• How much effort will it take? To paraphrase Einstein, "if you can't size it, you do not truly understand it."
• "What problem are you trying to solve?" This is my superpower question. While defining value is often difficult and understanding the user is sometimes challenging, I've rarely found a group that couldn't describe a problem they faced.

Product Backlog Refinement: Do it Early, Do it Often.

I hope this article will help you better understand the need for this ongoing activity and to give you a resource you can work with your teams and leaders to educate them.

Refine early, refine often, and generate greater value.

The Backlog Refinement Meeting is by far the most recognizable of the many activities associated with product backlog refinement. This helps to understand why refinement is often thought of as an event. For tips on running a Backlog Refinement Meeting, read The Keys to Effective Product Backlog Refinement.