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?"
The use of a metaphor helps gain clarity here. Let’s look at a sprint as a Value-Creating Machine. A Sprint Machine.
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.
With a solid understanding of "What" refinement is, let's step beyond the metaphor to answer some of the "Why?" questions.
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!!!”
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.
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).
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:
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:
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.
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.
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.
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe