Answering: “A Scrum Team has been working on a product for 9 Sprints. A new Product Owner who is new to Scrum joins the team and understands she is accountable for Product Backlog. However, she is unsure about the purpose of the Product Backlog. She has read that the Product Backlog should be a list of all user features for the product. She goes to the Scrum Master asking where to put the other types of requirements that are going to be taken into account. Are all of the following types of requirements acceptable on a Product Backlog?”

Yes. Every kind of work the product needs, including stability, performance, documentation and fixes, belongs on the one Product Backlog. Many new Product Owners assume the backlog is only for user features, and this question checks that you know it is not.

Exam Question

A Scrum Team has been working on a product for 9 Sprints. A new Product Owner who is new to Scrum joins the team and understands she is accountable for the Product Backlog. However, she is unsure about the purpose of the Product Backlog. She has read that the Product Backlog should be a list of all user features for the product. She goes to the Scrum Master asking where to put the other types of requirements that are going to be taken into account. Are all of the following types of requirements acceptable on a Product Backlog?

• Stability requirements
• Performance requirements
• Product Functionality
• Documentation
• Fixes

(choose the best answer)

A. Yes, they all belong on the Product Backlog. Product Backlog is supposed to be the “single source of truth” for all the work for the product.

B. No. Product Backlog is a tool for the Product Owner. The Product Owner represents the users and stakeholders. Other types of requirements should be managed separately by the Developers. They are not the Product Owner’s concern.

Correct Answer

A. Yes, they all belong on the Product Backlog.

Why This Is the Correct Answer

The Scrum Guide calls the Product Backlog “an emergent, ordered list of what is needed to improve the product” and “the single source of work undertaken by the Scrum Team.” Nothing in that definition limits it to user-facing features. Performance and stability work, documentation and bug fixes all take capacity from the same Developers, so they need to be visible and ordered against everything else. If they lived somewhere else, the Product Owner could not make honest trade-offs about value.

Why the Other Options Are Wrong

B. No, other requirements should be managed separately by the Developers. A second list kept by the Developers would hide work from the Product Owner and the stakeholders, and it would break the idea of a single source of work. The Product Owner orders all of it, usually after talking with the Developers about technical risk and dependencies.

Exam Tip

Watch for answers that split work into “business” and “technical” lists. In Scrum there is one Product Backlog per product, and any option that creates a second backlog is almost always wrong.

Key Takeaways

• One product, one Product Backlog, holding every kind of work.
• Non-functional work such as performance and stability is ordered by value like everything else.
• The Product Owner stays accountable for the whole list, even for items the Developers propose.