Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken.
Myth 5: In Scrum, the Product Backlog is prioritized
Today we bust the myth is that the Product Backlog is ‘prioritized’, ‘ordered by priority’ or ‘ordered by importance’.
Busting the Myth
The Scrum Guide states that the Product Backlog is an ‘ordered list’ of everything that is known to be needed in the Product. It is not a prioritized list. The distinction may seem trivial, but it has far-reaching consequences. In fact, after reading this post you’ll see that ordering items solely by their priority is often not the best way to maximize value.
To be fair, this myth demonstrates how Scrum is constantly evolving and changing (as expressed in the Scrum Guide). Before 2011, the Scrum Framework defined the Product Backlog as a ‘prioritized list’. This was changed after 2011 to reflect more clearly how the ordering of the Product Backlog was intended.
Prioritizing versus ordering?
A great way to make this ‘seemingly trivial’ difference very obvious, James Coplien uses the example of building a house in the tropics. With the heavy downpour that occurs every afternoon, it is important to get a roof over your head as soon as possible. The Product Backlog for your house will contain all the things that make up a house, like doors, windows, walls and obviously a roof. If you were to order this Product Backlog solely by priority, the roof would certainly end up on top. It needs to keep you dry. But this ordering does not reflect how you’re actually going to build your house. You can’t build a stable roof without walls, and you can’t build walls without a foundation. So instead of starting with the roof, you’ll probably start with the foundation of your house. The order of the Product Backlog will be influenced by such things as dependencies, efficient use of materials, availability of third parties and building codes. Only ordering by priority is not going to get you a stable, robust and safe house to get you through those wet and rainy afternoons.
The focus on ordering (over ‘prioritization’) underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximizes value.
If a Product Backlog is simply a prioritized list, it is tempting to conclude that ‘these 15 features are high-priority, these 23 are medium-priority and these 10 are low-priority’. It can easily lead a Product Owner to assume that it doesn’t matter which of the high-priority features are delivered in which Sprint, as long as they are delivered before any of the others. This closes opportunities for optimizing value, much like the example of the roof. We once made the mistake of asking a Product Owner which items he felt were most important, as that would inform the order on the Product Backlog. “They’re all important to me. I don’t want to have to choose” was the irritable response. By framing the Product Backlog as a prioritized list, we oversimplify the role of the Product Owner. Instead, we should have asked: “What ordering of items will help you return on your investment as soon as possible?”.
By framing the Product Backlog as a prioritized list, we oversimplify the role of the Product Owner.
Finally, the focus on ordering (over ‘prioritization’) emphasizes that the Product Backlog must be considered as a whole when re-ordering items. The Product Backlog expresses the order of delivery of items, and thus how value is generated over time. Every change to the ordering of the Product Backlog changes how value is generated. If we simply focus on priority, it is tempting to get bogged down in the local optimization of how two items are prioritized in relation to each other; "Is this item more important than that item?".
Factors that influence ordering
There are countless factors that influence the potential ordering of a Product Backlog, including:
- Dependencies between Product Backlog Items, external parties and within the Development Team can influence the ordering. Certain items may be easier to implement when other items have been implemented first. Or an external supplier needs to do work before other items can be implemented;
- The risks associated with implementing, or not implementing, a particular item. Perhaps the implementation of one item helps us learn something important about the product we’re developing. Does a particular technology offer a good foundation for further development? Do users respond well to this prototype of a new feature, before proceeding?;
- The knowledge of a Development Team may be a consideration. Perhaps implementing an item helps a team learn something that is needed for further development. Or perhaps a certain set of items can only be implemented when the Development Team has acquired the required knowledge;
- The needs of the customers influence the ordering, as items that address needs of our customers deliver value for our business (increased revenue, sales, being able to bring a new group of customers in, etc);
- The cost of implementation influences the ordering. Perhaps there is work on the Product Backlog that - once implemented - simplifies work for future items. Like setting up a continuous deployment pipeline, refactoring parts of the product or implementing that automated import script. Cost may also be a consideration on the level of individual items, as the cost of development may outweigh priority, value or risk;
- Business conditions may change, prompting some items to be moved up or down the Product Backlog;
- The cost of delay influences ordering. Donald Reinertsen considers this the cost of delaying the implementation of one feature over another;
Sameer Patil has written a far more extensive post on the various considerations that come into play when ordering the Product Backlog. The key message to take from this is that the Product Backlog should be continuously (re)ordered to maximize the value delivered each Sprint. What is valuable depends on many contextual factors. Scrum doesn’t, and can’t, offer a one-size-fits-all technique for arriving at the best ordering.
Tips
- As a Scrum Master, you can help a Product Owner arrive at an optimal ordering by asking powerful questions. “Which items help address the biggest assumptions we’re making?”, “If you were to stop three sprints from now, which items would certainly have to be included?”, “If you could only keep 20% of the Product Backlog, which items would you keep?” or “How can we optimize the ordering to address dependencies?”;
- The Liberating Structure ‘Min Spec’ can be used to help inform which items on the Product Backlog are absolutely critical to success, and which aren’t;
- As a Scrum Master, help the Product Owner find alternative strategies for ordering the Product Backlog. Coach the Product Owner to inspect the ordering frequently, based on insights that have emerged during development;
- The Sprint Review is an excellent opportunity to inspect and adapt the ordering of the Product Backlog with the Development Team and stakeholders;
Closing
In this post, we busted the myth that the Product Backlog is ‘prioritized’. Although a seemingly trivial change of wording, the Product Backlog is ‘an ordered list’ instead. By framing the Product Backlog as a ‘prioritized list’, we shortcut the active role that a Product Owner needs to play. He or she is responsible for continuously (re)ordering the Product Backlog to maximize the value delivered each Sprint as work progresses and insights emerge. As a closing, we offered a few tips to help you understand the Product Backlog in a broader sense.
What do you think about this myth? Do you agree? What are your lessons learned?
Want to separate Scrum from the myths? Join our Professional Scrum Master orScrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses