What is a Product Backlog in Scrum? Who Owns It?

Product Backlog is the single source of truth for all that is needed in the product and a prioritized list of product requirement changes. The Product Owner is responsible for the content, availability, and prioritization of the Product Backlog items.

The Product Backlog is an evolving list. The initial version only lists the first and most well-known requirements (no need to be thoroughly understood). The Product Backlog evolves as the product and development environment change. It is dynamic and frequently changes to identify what is necessary to make the product viable, competitive, and useful. As long as the product exists, the Product Backlog exists.

The Product Backlog lists all features, use cases, user stories, improvements, and bug fixes planned for future releases. A Product Backlog Item (PBI) includes description, sequence, and estimated effort.

Product Backlog Items (PBIs) are typically ordered by value, risk, priority, and necessity. They are sequenced from highest to lowest priority, with each item having a unique order. The topmost items in the Product Backlog must be developed immediately. The higher the ranking, the more urgent the item, and the more carefully you must consider its value—your understanding of value becomes more consistent.

Scrum Product Backlog

Higher-ranked items in the Product Backlog are clearer and more specific than lower-ranked ones. These items can be estimated more accurately based on clearer content and more detailed information. In other words, the lower the priority of a backlog item, the less detailed it becomes. The Product Backlog items developed by the team in a Sprint are granular and broken down into smaller tasks, so that any item can be “done” within the time-box. Product Backlog items that the development team can “complete” in a Sprint are considered to meet the **definition of “Ready”** and can be selected during the Sprint Planning Meeting.

Scrum Process

As the product is deployed, value is realized, and feedback from the market grows, the Product Backlog becomes larger and more detailed. Since requirements never stop changing, the Product Backlog is a living artifact. Changes in business needs, market conditions, and technology may cause changes in the Product Backlog.

While multiple Scrum teams may collaborate on developing a product, only one Product Backlog describes the next work for the product. Then, you need to use attributes to categorize Product Backlog items.

Through Product Backlog Refinement, details, estimates, and ordering are added. This is an ongoing process where the Product Owner and the development team collaborate to discuss the details of each backlog item. Items are reviewed and revised within the Product Backlog. However, the Product Owner can update any item in the Product Backlog at any time and make decisions as needed.

Product Backlog Refinement is an ongoing activity—not a time-boxed one—carried out by the Product Owner and the development team. The development team typically has the domain expertise to self-improve. However, when and how refinement is done is a decision of the Scrum team. Product Backlog refinement usually takes no more than 10% of the team’s development time.

Product Backlog Refinement Meeting

The development team is responsible for all estimation work. The Product Owner can influence the team’s decisions by helping them weigh trade-offs. However, the final estimate is determined by the people doing the work.

Monitoring Progress Through Sprint Goals

At any time, the remaining effort to achieve the Sprint Goal can be deducted from the cumulative work completed. The Product Owner must track the total remaining effort at least after each Sprint Review. The Product Owner compares this amount with the remaining effort from previous Sprint Reviews to assess progress toward the expected work at the required time. This information is transparent to all stakeholders.

Scrum does not consider the time spent on items in the Product Backlog. We only care about the remaining work and the date variable.

Various charts or burn-down charts and other planning practices can be used to forecast progress. They have proven to be useful. However, this does not replace the importance of empirical thinking. In complex environments, what will happen is unknown—only what has happened can be used to make forward-looking decisions.

Scrum Sprint Progress