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.
Imagine you have a Product Backlog refined out a year in advance. Your team operates in a highly dynamic environment with competitors who release innovations to the market at least once per quarter. What happens if you face a new business opportunity or business needs change? Those carefully refined PBIs, which you will not get to for a year or more, could become obsolete.
Scrum is founded upon empiricism — or making decisions based on what is known — and on lean thinking, which among other things, includes eliminating waste and focusing on the essentials of what you need. Making decisions more than a year in advance can limit the team’s ability to take advantage of new information, thus hampering empiricism. In addition, a Product Backlog that contains PBIs you might never deliver is a form of lean waste. You’ve invested resources into creating and refining work that you will never deliver.
Conduct an analysis. As the Product Owner, if you are not familiar with the lower ordered Product Backlog items, your team might be refining too much work. If a significant percentage of the refined work in your Product Backlog has become obsolete, that might also indicate you are refining too much work.
What to do if you have too much?
If your Product Backlog contains work you might never deliver, it’s time to clean house. You can delete or archive older PBIs depending on your organization’s needs. Regularly cleaning up your Product Backlog is good practice, but the exact frequency is up to you. Many teams clean out their Product Backlogs yearly, and others clean up more frequently.
Cleaning up the Product Backlog is one way to eliminate waste. Having to wade through too many PBIs takes attention away from more important work. Conducting a regular review of your Product Backlog and deleting or archiving older PBIs creates room for higher-value work. If you have an unmanageable amount of PBIs in your Product Backlog, you may even consider cutting over to a new Product Backlog and making a fresh start.
But stakeholders want to know what’s next!
Eliminating waste doesn’t mean we don’t plan for what’s next. It just means that we may not have fully refined all plans.
Higher ordered PBIs in the Product Backlog contain more detail and should be sized to be completed within one Sprint. However, the Product Backlog may include stories that are not yet refined but tentatively planned for later. These unrefined PBIs represent what is planned ‘next,’ but they might not contain much detail, are loosely ordered and might not be sized.
Product Owners can create a visual representation of the way forward, which may or may not include unrefined PBIs. One way to do this is to create a roadmap. The roadmap is a forecast about what might be next for the Scrum Team and frequently shows the team’s best guess for when they will deliver as yet unrefined work items.
A roadmap is helpful for stakeholders, Developers, and other Scrum Team members. It helps set stakeholders' expectations and gives Scrum Teams additional context for their work. Knowing what’s next may change how Developers approach their current work.
Conclusion
Finding the right balance of refined work for YOUR team is an art and is a strategic decision the Product Owner makes. The goal is to find the optimal balance for your team that eliminates the waste associated with investing too much time in the Product Backlog and the need to have enough ready work to avoid idle time for the Scrum Team.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
- Applying Professional Scrum
- Introductory class for those new to Scrum
- Professional Scrum Master
- Geared towards Scrum Masters coaching teams
- Professional Scrum Master II
- Advanced class for Scrum Masters
- Professional Agile Leadership
- For leaders and managers of Agile teams
- Professional Scrum Product Owner
- For Product Owners
- Professional Scrum Product Owner - Advanced
- Advanced class for Product Owners
- Professional Scrum with Kanban
- For anyone interested in learning about implementing Kanban principles within a Scrum Team
- Scaled Professional Scrum with Nexus
- For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Rebel Scrum.
