Scrum Rules: The Product Backlog Relates to a Single Product

Scrum Teams work on one product at a time. The Product Backlog represents all of the work that needs to be done on that single product.

The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product. Multiple teams working on a single product, therefore, work from a single, shared Product Backlog. Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain. Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be. Having a single product to work on creates focus in both the business and technical domains.

There are three effective approaches to consider in applying this rule in a team which currently has PBIs from more than one product or system. First, carefully consider the business value of the work that is planned. Often, one product or system embodies a large proportion of the business value. The Product Owner of the team may need to create financial models of the various products and/or systems. If one of the products / systems is clearly the most valuable, then the Scrum Team should focus on that product / system for multiple Sprints. The second option is to split the Scrum Team into two (or more) smaller teams that are focused on a single product / system each. This technique requires that a team be relatively large to begin with and that people are sufficiently multi-skilled to create fully capable teams. Smaller teams may require that those teams formally abandon Scrum and work with something like Crystal Clear, Kanban or OpenAgile that are suitable for such teams. Even switching to a different agile method in this case would be respecting the spirit of Scrum in that focus is such an important driver of high-performance teams. The third option is the easiest: split the PBIs for each product / system into separate Product Backlogs and have the team switch between Product Backlogs on a Sprint-by-Sprint basis. This technique ensures that the Scrum Team is completely focused for the duration of the Sprint. Additionally, this is the only technique that works when a single team is responsible for several products / systems that all have similar value. This approach still suffers in that the team is doing a major task switch between Sprints and so their focus is not as strong as with the other two approaches. In this third approach, it is important to have just one Product Owner for the team who manages the multiple Product Backlogs so that the team membership maintains full cohesion and is stable over an extended period of time. One additional consideration should be kept in mind: if the Scrum Team is doing support for multiple products rather than product development for multiple products, Kanban is a much more appropriate method for that team to use.

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product…. As long as a product exists, its Product Backlog also exists…. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

— The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…