A common question I hear in Scrum training sessions and coaching sessions is, "How much improvement should we make on the Product Backlog and how much detail should there be in the Product Backlog?" First, let's look at the Scrum Guidelines. Product Backlog Refinement According to the Scrum Guidelines, Product Backlog Refinement is the act of adding detail, estimation, and order to the items in the Product Backlog. But Scrum doesn't dictate how you do it, and for good reason. Refinement is an ongoing process. It never stops because needs and opportunities never stop changing. Specifying everything up front creates waste and delays the delivery of value. Different products and different teams will have unique needs in terms of frequency, technology, and level of detail. Even the same Scrum team working on the same product needs to improve over time how they refine the Product Backlog to adapt to new situations. Scrum teams need to figure out what works for them. So how do they do it? Self-organization and empiricism. Apply the Goldilocks principle to help teams experiment and find what works best for them by checking and tweaking. Goldilocks Principles and Product Backlog Refinement The Goldilocks principle is to find something "just right" for your team. The goal is to strike a balance between getting enough benefit from the activity and minimizing potential waste.
Let’s first look at the 6 benefits of Product Backlog refinement: increase transparency articulate value Break things down into consumables reduce dependence predict integrated learning Now let's take a deeper look at each one and see how we can apply the Goldilocks principle. I'll ask you a few introductory questions in each of these 6 benefit areas to help your team determine if the weather is 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 can increase the transparency of what you plan to deliver and industry mailing list progress. Goldilocks Question How well do stakeholders and the Scrum team know about the product plan? How often are interested stakeholders surprised by what was delivered? #2 – Articulate the value When you articulate the details of the value, the results you are trying to achieve with a Product Backlog Item (PBI) are clearer. why do you want this? What are user benefits? What are business interests? This helps the development team build the right thing to meet the needs. This affects the content of requests, estimates, and orders as the product owner and development team determine what is actually needed. This dialogue creates a shared understanding. Goldilocks Question During the Sprint, do you often find that there is no consensus on what the business needs or what you are building? How often do you find that the PBI is not meeting user or business needs during the Sprint Review or post-release? #3 –
Break things down into consumables You want the PBI to be small enough that the development team can complete multiple in a Sprint. Having multiple PBIs in a Sprint gives the team some flexibility in meeting Sprint Goals and delivering "Done" Increments. Goldilocks Question How often do you not deliver "done" increments? How often have you missed your Sprint goal? When is this due to finding out in the middle of the Sprint that the PBI is much larger than you thought or that the slices are not thin enough? #4 – Reduce dependencies Dependencies often turn into roadblocks and bring teams to a standstill. While you may not be able to avoid all of them, you should try to minimize them. This is especially important for dependencies outside the Scrum team. You can slice and split PBI in different ways. You can reorder or collaborate with other teams to help resolve dependencies ahead of time. There are many options, at least, you want your dependencies to be transparent. Goldilocks Question During the Sprint, how often do you discover dependencies that compromise the Sprint goals? How long will the PBI in a sprint be "blocked" by dependencies?