Agile Glossary

Product Backlog

What is Product Backlog?

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.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
Backlog grooming is when the product owner and some, or all, of the rest of the team refine the backlog on a regular basis to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now