A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome.
The product backlog is the single authoritative source for things that a team works on. That means that nothing gets done that isn’t on the product backlog. Conversely, the presence of a product backlog item on a product backlog does not guarantee that it will be delivered. It represents an option the team has for delivering a specific outcome rather than a commitment.
It should be cheap and fast to add a product backlog item to the product backlog, and it should be equally as easy to remove a product backlog item that does not result in direct progress to achieving the desired outcome or enable progress toward the outcome.
Product backlog items take a variety of formats, with user stories being the most common. The team using the product backlog determines the format they chose to use and looks to the backlog items as reminders of the aspects of a solution they may work on.
Product backlog items vary in size and extent of detail based in large part on how soon a team will work on them. Those that a team will work on soon should be small in size and contain sufficient detail for the team to start work. The team may establish a definition of ready to indicate their agreement on the information they’d like to have available in order to start working on a product backlog item. Product backlog items that are not slated for work may be fairly broad and have little detail.
The sequence of product backlog items on a product backlog changes as a team gains a better understanding of the outcome and the identified solution. This reordering of existing product backlog items, the ongoing addition and removal of product backlog items, and the continuous refinement of product backlog items give a product backlog its dynamic characteristic.
A team owns its product backlog and may have a specific role – product owner – with the primary responsibility for maintaining the product backlog. The key activities in maintaining the product backlog include prioritizing product backlog items, deciding which product backlog items should be removed from the product backlog, and facilitating product backlog refinement.
A product backlog can be an effective way for a team to communicate what they are working on and what they plan to work on next. Story Maps and information radiators can provide a clear picture of your backlog for the team and stakeholders.
The product backlog can be represented in physical form using index cards or sticky notes, or it may be represented in electronic forms such as a text file, spreadsheet, or one of the many backlog management tools that exist. Electronic boards are the better option for a team that has remote members or collects a great deal of supplementary information about product backlog items. Physical boards offer the advantage of making the product backlog continuously visible and concrete during discussions around the product backlog.
Also Known As
The product backlog is often referred to as simply the backlog. This entry clarifies the term product backlog to avoid confusion with sprint backlogs, which are related, but a different concept.
Scaled Agile Framework (SAFe) introduced a series of backlogs to replace the product backlog. Each type of backlog is intended to contain a specific granularity of backlog items based on a complicated backlog item hierarchy:
- The portfolio backlog contains the different initiatives an organization is considering (referred to as epics).
- The solution backlog contains high-level backlog items (referred to as capabilities and enablers) that represent aspects of a solution
- The program backlog contains backlog items (referred to as features) that represent aspects of a solution.
- The team backlog contains backlog items (user stories and others) that a team works on.
Expected Benefits
Product backlog items act as placeholders for future conversations about an option for achieving your desired outcome. That means a team doesn’t have to have an idea fully fleshed out before adding it to the product backlog. When a product backlog item is initially added to a product backlog it only needs to have enough information to remind the team what the option was. A product backlog item only needs to be fully described when a team is about to start work on it.
The dynamic nature of a product backlog provides teams with a way to manage their learning about the desired outcome and potential ways to deliver that outcome. The product backlog does not need to be complete when a team starts work, so the team can start with an initial idea and add new product backlog items as they learn more.
Just because something is on a product backlog does not mean that it has to be delivered, so a team can remove product backlog items that they discover do not contribute toward achieving the desired outcome. This means that a team can avoid producing extraneous outputs that do not add value and spend their time working on truly valuable changes.
Teams can use the product backlog to avoid wasting time debating whether an option is valuable or not based on limited information. When a new idea presents itself, the team can add a product backlog item as a reminder to investigate the idea further. The team can then prioritize consideration of that idea alongside other items, and remove the product backlog item if the idea proves to not provide progress toward the desired outcome.
Common Pitfalls
The product backlog should not be confused with a requirements document. While it serves as an entry point to requirements information about the product it has some distinct differences from requirements documents:
- Product backlog items are necessary but not sufficient to describe the intended changes to the product. A complete understanding of the product comes from conversations that occur about the individual product backlog items and supplementary information that a team chooses to record about the product backlog item.
- In contrast to something that appears in a requirements document, the inclusion of a product backlog item in a product backlog does not guarantee that it will be delivered.
- In contrast to a requirements document which is baselined and is expected not to change after a certain point, the product backlog evolves as an understanding of the product evolves.
If a team starts using an electronic tool before they have settled on their approach to product backlog management, the tool can drive a team’s approach to product backlog management. The team may also get hung up on how to use the tool rather than selecting the process that works best for them.
It’s possible for a product backlog to get too large to be effectively managed. This happens if a team adds every idea that gets suggested for addressing the outcome but never explores the ideas or removes the items that won’t be delivered. Product backlogs can also grow to an unmanageable size if all large product backlog items are split into smaller product backlog items too far in advance of when the team will work on them.
