The Product Backlog

Contrary to popular belief, the Product Owner does not have dictatorial powers regarding the composition and order of the Product Backlog. Instead, Scrum as a framework is based on a delicate system of checks and balances, collaboration, and joint decision-making to mitigate risk; for example, the Product Owner falling in love with their solution over the problem of the customers. Learn more about critical Product Backlog principles, from the size and growth of the Product Backlog to whether a Product Backlog is necessary in the first place. (Some lean practitioners dispute its existence is justified.)

The Product Backlog According to the Scrum Guide

First, let us look at the Scrum Guide’s current edition to understand Product Backlog principles better:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

[Product Owner] decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Source: Scrum Guide 2020.

For a complete overview of Product Backlog quotes from the Scrum Guide, see the Scrum Guide Reordered 2020.

Scrum, being a tactical framework, is good at effectively getting validated hypotheses into the hands of the customers to close the learning loop, allowing for the inspection of the initial assumption and the decision process to build an Increment and subsequently adapting the preparations for the next Sprint. 

But ultimately, the first challenge in a complex environment is figuring out what is worth building. Therefore, a successful Scrum team needs to abandon the idea that the Product Owner miraculously identifies how to proceed in the best interest of customers, the organization, and the team. Instead, aim to integrate everyone into building a system that succeeds in feeding validated hypotheses of what might be valuable into the Product Backlog. (Learn more: Product Backlog Refinement: 14 First Principles.)

In other words, the mere existence of a Product Backlog does not guarantee success, as Scrum is equally well-suited to build things no customer wants effectively.

Product Backlog Principles

These are my 14 Product Backlog principles for successful Scrum teams:

1. Product Goals drive outcomes: The Product Backlog reflects the Scrum team’s Product Goal. It is not just a repository or accounting system of all requirements thrown at the team. As plans change in complex environments, so does the interpretation of the team’s Product Goal and, consequently, the composition and order of the Product Backlog items. Product Backlogs are, by definition, dynamic.
2. Product Owner prerogatives: The Product Owner is paid to maximize the value of the work of the Developers on behalf of customers and the organization—within the given constraints. They do so by managing the Product Backlog based on content and ordering. However, contrary to popular belief, this does not imply that they also have dictatorial powers. Scrum is a delicate system of checks & balances; therefore, the other team members should challenge every proposal of the Product Owner: Is there nothing of a higher value we can tackle, Product Owner?
3. It’s part of a system: The Product Backlog is a critical but not the only part of a system organizing the flow of value-creating work through the Scrum team. The product discovery part feeding into the Product Backlog deserves equal attention.
4. Risk-mitigation: The purpose of the Product Backlog is risk mitigation. In and of itself, the Product Backlog is of little other value.
5. #NoPolitics: Using the Product Backlog as a pacifier for annoying stakeholders is tempting. However, only transparency and respect solve that problem. If the Scrum team does not consider working on a requirement, tell them so. Instead, adding those futile requirements to the Product Backlog and letting them rot will only postpone this conversation. Then, when it finally happens, rest assured emotions will burden that conversation.
6. Growth: If your Product Backlog grows faster than the Scrum team can deliver Product Backlog items, you are probably heading toward becoming a feature factory.
7. Size matters: Any Product Backlog exceeding more work than the Scrum team can handle in 2-4 Sprints is wasteful. Product Backlogs do not scale. (Some lean-minded people may even argue the mere existence of a Product Backlog already reflects waste.)
8. Every item added is expensive: Adding a Product Backlog item may only need little effort. It may seem that enlarging the Product Backlog is free of charge and, therefore, an excellent strategy to avoid “missing out” on something important. However, the problem is accumulating supposedly “free” items as the cost of dealing with increasingly large Product Backlogs rises exponentially.
9. Storage for ideas: Product Backlogs seem attractive places to overwhelm with ideas, thoughts, and sketches. They gotta go somewhere, don’t they? Absolutely, just do not misuse the Product Backlog for this purpose, as it represents a place of higher build certainty. Ensure that you only add items to the Product Backlog that the Scrum team validated before.
10. The trash bin is your friend: Delete Product Backlog items that the Scrum team hasn’t addressed for more than eight weeks. Most likely, those are noise anyway. Instead, if they are a signal, they will come back.
11. No guarantees: A Product Backlog reflects the best use of the Scrum team’s time at a specific moment. It is a snapshot of a complex, dynamic situation. Therefore, if a requirement makes it into the Product Backlog, it does not imply that the team will build it. Maybe, there is something more valuable to choose instead.
12. Shipping the Product Backlog: The Scrum team does not ship the Product Backlog based on its order at the moment of the Sprint Planning. Instead, the Scrum team identifies the Sprint Goal collectively, which then informs the content of the Sprint Backlog. In most cases, the Product Backlog can contribute items to the Sprint Backlog. However, there is no automatism. If necessary, the Developers will create all work items essential to accomplish the Sprint Goal on the spot. If this is the rule rather than the exception, please ask yourself why you spend time creating a Product Backlog. Just stop doing so.
13. Shipping builds trust: Nothing is better suited to build trust with stakeholders than shipping valuable Increments. So use the Product Backlog to support the Scrum team in that capacity only.
14. Following a plan: We do not get paid to create comprehensive Product Backlogs; for example, in the act of upfront planning for the next twelve months. Busily adding Product Backlog items to Jira does not create value but dangerous noise; think of loss aversion. Merely “following a plan” is a much easier sell when your Product Backlog has reached an epic size and thus becomes elevated to asset level. Nevertheless, it is not more than a tool. 

Conclusion

The Product Backlog can be a critical artifact for your Scrum team’s path to success. However, in a complex environment without experts knowing the answers to all problems, merely stuffing all requirements thrown at you into a Jira project won’t do the trick. More important than the list itself is creating a process around feeding validated hypotheses into the Product Backlog. For that purpose, consider the above-mentioned Product Backlog principles to help you succeed with this creative challenge.

What Product Backlog principles have worked for you? Please share with us in the comments.