A common question I hear in Scrum training courses and in coaching sessions is, “how much Product Backlog refinement should we do and how much detail should be in the Product Backlog?”
First, let’s look at the Scrum Guide.
Product Backlog Refinement
According to the Scrum Guide, Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. But Scrum doesn’t prescribe how you do it, and for good reason.
Refinement is an ongoing process. It never stops because requirements and opportunities never stop changing. Detailing everything up front would create waste and also delay the delivery of value.
Different products and different teams will have unique needs in terms of frequency, techniques, and level of detail.
Even the same Scrum Team working on the same product will need to evolve how they do Product Backlog refinement over time to fit new situations. Scrum Teams needs to figure out what works for them. So how do they do that?
Self-organization and empiricism.
Apply the Goldilocks Principle to help a team experiment and find what works best for them through inspection and adaptation.
The Goldilocks Principle and Product Backlog Refinement
The Goldilocks Principle is about finding what is “just right” for your team.
The goal is to balance gaining enough benefits from the activity while minimizing the potential waste.
Let’s first look at the 6 benefits of Product Backlog refinement:
- Increase transparency
- Clarify value
- Break things into consumable pieces
- Reduce dependencies
- Forecasting
- Incorporate learning
Now let’s dive deeper into each of these to see how we can apply the Goldilocks Principle. I’m going to give you a couple of starter questions in each of these 6 benefit areas to help your team figure out if it’s too hot, too cold, or just right.
#1 – Increase Transparency
The Product Backlog is an artifact that helps provide transparency. It is the “single source of truth” for what is planned in the product. Adding details increases transparency to what you plan to deliver, as well as your progress.
Goldilocks Questions
- How well do stakeholders and the Scrum Team understand what is planned for the product?
- How frequently are the interested stakeholders surprised by what was delivered?
#2 – Clarify Value
When you clarify the details around value, the outcomes you are trying to achieve with the Product Backlog Item (PBI) are more clear. Why do you want this? What is the user benefit? What is the business benefit?
This helps the Development Team build the right thing to meet the need. This can affect what is requested, the estimate, and the order as the Product Owner and Development Team figure out what is actually needed. This conversation creates a shared understanding.
Goldilocks Questions
- How often do you discover during a Sprint that there is not a shared understanding of the business need or what you are building to meet it?
- How frequently do you discover in a Sprint Review or after a release that a PBI does not meet the user or business need?
#3 – Break Things into Consumable Pieces
You want PBIs to be small enough that a Development Team can complete more than one in a Sprint. Having more than one PBI in a Sprint gives the team some flexibility to meet a Sprint Goal and deliver a “Done” Increment.
Goldilocks Questions
- How often are you not delivering a “Done” Increment? How often are you not meeting a Sprint Goal?
- When is this attributed to discovering mid-Sprint that PBIs are much bigger than you thought or not sliced thin enough?
#4 – Reduce Dependencies
Dependencies often turn into impediments and can grind a team to a halt. While you may not avoid them all, you should try to reduce them where possible. This is especially important for dependencies outside the Scrum Team. You can slice and split the PBIs in different ways. You can re-order, or you can collaborate with other teams to help resolve the dependency in advance. There are many options, and at the very least, you want the dependencies to be transparent.
Goldilocks Questions
- How often do you discover dependencies during a Sprint that jeopardize the Sprint Goal?
- How long do PBIs in a Sprint stay “blocked” by dependencies?
- When do you have to re-order the Product Backlog to account for dependencies? And how much of an impact does this have on the Product Owner’s ability to optimize value?
#5 – Forecasting
A refined Product Backlog combined with historical information about the Scrum Team’s ability to deliver working product helps you forecast. Some products need to forecast several Sprints into the future to help communicate release expectations with stakeholders. Other products will not have a need to do forecasting beyond the current Sprint. Most products fall somewhere along this spectrum.
Related to forecasting, you also may need a refined Product Backlog in order to get funding. Scrum does not forbid up-front planning. Scrum simply says to consider your effort to do so, the potential waste, and the fact that you cannot perfectly predict the future in a complex domain no matter how much analysis you do.
Goldilocks Questions
- How much lead time is necessary for users, customers, and other stakeholders to implement a new feature or function? What is the impact if they have less lead time?
- How much detail do users, customers, and other stakeholders need in release forecasts? What is the impact if they have less detail?
#6 – Incorporate Learning
Empiricism is about incorporating the learning you gain as you build the product, as you better understand how to realize the product vision, as you see changes happening in your environment.
Goldilocks Questions
- How are you adapting the Product Backlog to reflect new learning about the product’s evolving capabilities and how users are responding to the changes?
- What opportunities have been missed? What prevented you from responding sooner?
Pulling It All Together
You’ve discussed the Goldilocks questions about refinement benefits with the Scrum Team. (Sprint Retrospectives are a great opportunity to regularly have these conversations.) Now it’s time for the Scrum Team to decide how to adapt their process for Product Backlog refinement. There is a reason these are open questions and not simple yes/ no questions.
You are looking for balance, or that “just right” spot. You want to achieve enough of the benefits of refinement while minimizing your waste.
With the information gained from exploring 1-6, the Scrum Team can now consider these questionswith the balance of benefits and waste in mind.
Goldilocks Questions
- How frequently do you want to do refinement? And how much time do you want to spend detailing the Product Backlog?
- Who do you want to be involved in refinement? What knowledge and perspectives are needed? How will you enable shared understanding?
- How much of your Product Backlog do you want to be “Ready” before a Sprint? What does “Ready” mean to you?
- How do you want to communicate important details about PBIs? What methods are working well and what methods are not?
- How will you ensure you can see the whole and not get bogged down in details?