The Product Backlog is one of the three Scrum artifacts. It is the team’s to-do list that shows what to work on next. Each item on the list is called a Product Backlog item (PBI), and each PBI contains a description, sizing, and order. A well-refined Product Backlog is essential for high-performing Scrum Teams. Without it, teams will likely struggle to deliver a Done increment each Sprint.
So, how far out should the Product Backlog go?
Like many things in Scrum, the answer is, it depends. The team should avoid refining too far in advance if it’s working in a higher-risk environment involving frequent changes in technology, business needs, or other factors influencing the Product Backlog’s order and content. A Product Backlog refined out a bit farther may be appropriate for more stable environments experiencing fewer changes. Finding the right balance for YOUR team is what matters.
How do I find the right balance?
Here are two tools you can use to determine whether there is enough ready work in the Product Backlog.
Ready Story Forecast
PBIs are ready to be pulled into the Sprint if they have a description, are sized to be completed within one Sprint, and have been ordered. (Note that some teams use the complementary practice of creating a definition of ready and may add criteria to this list.) Refinement is the act of adding the description, completing the sizing and adding order to items in the Product Backlog.
A ready story forecast indicates how well refined your team’s Product Backlog is. If your team had to plan a Sprint tomorrow, would there be enough PBIs ready that you could pull into the Sprint? Would there be enough ready for two Sprints? Three? The number of Sprints you could support with ready PBIs equals the ready story forecast.
How do we measure it?
How you measure the ready story forecast depends on how your team sizes its work. If your team is using hours to size PBIs, then the calculation of the ready story forecast would depend upon hour estimates. For example, if the Scrum Team typically delivers 120 hours of work in an average Sprint, and the amount of currently ready stories adds up to 360 hours’ worth of work, your team has three Sprint’s worth of ready work and the ready story forecast is three.
Alternatively, your team can complete the ready story forecast using points instead of hours. For example, if your team closes an average of 100 points per Sprint and you have 300 points’ worth of ready PBIs, your team has three Sprints of ready work, and the ready story forecast is three.
If your team is using flow metrics and closing an average of 10 PBIs per Sprint and you have 30 refined PBIs, your team has three Sprints of ready work, and the ready story forecast is—you guessed it—three.
What is the right target? Again, it depends on your team’s environment. Your goal is to avoid having too few stories ready, which could create idle time. On the other hand, you want to avoid having too many stories resulting in waste if some stories become invalid or outdated over time.
How do you pick a target?
Finding the right balance of refined work is a strategic decision the Product Owner makes. Getting the Developers’ perspective to inform this decision is useful, and the ready story sentiment tool can help.
Ready Story Sentiment
Ready story sentiment is a qualitative measurement of how well the team prepared the Product Backlog for the most recent Sprint. One way to measure ready story sentiment is to discuss it at the Sprint Retrospective. Ask the Developers to rate how ready the Product Backlog was for the previous Sprint. You can use any point rating system you deem appropriate. In the image above, we show a scale of one to five, where one is awful, and five is fantastic. If your team scores the Product Backlog readiness as awful, ask them what they can do to make that better. Were stories sized appropriately, or was there not enough information? If the team scores the Product Backlog readiness as fantastic, that’s great, but follow up with assessing the return on investment for having “fantastic” PBIs ready? Have you invested too much?
So, is there such a thing as too much refined work?
When analyzing the performance of the Product Backlog, it’s worth considering whether your team has refined too much work.
Building and refining a Product Backlog is time-consuming. Many people think of the Developers’ time, but the Product Owner’s time is also a precious resource. Sometimes, it is easy to overlook that the creation of the Product Backlog itself is an investment. Like any other investment, we need to consider our return. A well-refined Product Backlog can accelerate teams and increase their ability to deliver a valuable increment each Sprint. But, there is such a thing as too much of a good thing. If the Product Backlog is refined too far out, it can become an example of lean waste.