Scrum is conceived asa simple structure, but sufficient for the delivery of complex products. Scrum is not a one-size-fits-all solution, a silver bullet, or a complete methodology. Rather, Scrum provides the minimum limits 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 misconceptions and myths surrounding Scrum. In this series of posts, we, your 'mythbusters'christian reference&barry overeem- It will address the most common myths and misunderstandings. PS: The big pictures are fromthea schucken.
Myth 5: In Scrum, the Product Backlog is prioritized
Today, we break the myth that the Product Backlog is 'prioritized', 'ordered by priority' or 'ordered by importance'.
Destroying the myth
The Scrum Guide states thatthe Product Backlog is an 'ordered list' of everything known to be needed in the Product. It is not a priority list. The distinction may seem trivial, but it has far-reaching consequences. In fact, after reading this post, you'll see that ordering items by priority alone 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 theScrum Guide). Prior to 2011, the Scrum Framework defined the Product Backlog as a "priority list". This was changed after 2011 to more clearly reflect how the backlog order was planned.
Prioritize vs. Order?
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 rain that falls every afternoon, it is important to have a roof over your head as soon as possible. The Product Backlog for your home will contain all the things that make up a home, such as doors, windows, walls, and obviously a roof. If I were to sort this Product Backlog by priority alone, the ceiling would certainly be at the top. You need to keep it dry. But that order does not reflect how you are 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 portfolio will be influenced by things like dependencies, efficient use of materials, third-party availability, and building codes. Sorting by priority will not provide you with a stable, solid and safe home to spend wet and rainy afternoons.
The focus on ordering (on 'prioritization') underscores the active role the Product Owner must continually play in ordering and reordering work in a way that maximizes value.
If a Product Backlog is simply a list of priorities, it's tempting to conclude that "these 15 features are high priority, these 23 are medium priority, and these 10 are low priority." This can easily lead a Product Owner to assume that it doesn't matter which high-priority features are delivered in which Sprint, as long as they are delivered before anyone else. This closes out value optimization opportunities, just like the ceiling example. We once made the mistake of asking a product owner which items he considered most important, as this would inform the order in the product backlog. “Everyone is important to me. I don't want to have to choose," was the irritated response. By framing the Product Backlog as a prioritized list, we oversimplify the role of the Product Owner. Instead, we should have asked, "Which item order will help you recover your investment the fastest?"
By framing the Product Backlog as a prioritized list, we oversimplify the role of the Product Owner.
(Video) Difference Between Product Backlog and Spring Backlog in Agile
Finally, the focus on ordering (on 'prioritization') emphasizes that the Product Backlog must be considered as a whole when reordering items. The Product Backlog expresses the order in which the items are delivered and, therefore, how value is generated over time. Changing the order of the product portfolio changes the way value is created. If we simply focus on priority, it's tempting to get bogged down in local optimization of how two items prioritize each other; "Is this item more important than that item?"
Factors Influencing Order
There are numerous factors that influence the potential order of a Product Backlog, including:
- Dependencies between product backlog items, parties outside and within the development team can influence the order. Certain elements may be easier to implement when other elements have been implemented first. Or a third-party vendor needs work before other items can be implemented;
- The risks associated with the implementation or non-implementation of a particular element.Perhaps implementing an item will help us learn something important about the product we are developing. Does a particular technology provide a good foundation for future development? Do users respond well to this prototype of a new feature before proceeding?
- Knowledge of a development team may be a consideration.Perhaps implementing an item will help the team learn something needed for further development. Or maybe a certain set of elements can only be implemented when the Development Team acquires the necessary knowledge;
- The customer's needs influence the order., since the elements that satisfy the needs of our clients add value to our business (increased income, sales, the ability to attract a new group of clients, etc.);
- The cost of implementation influences the order.Perhaps there is work on the Product Backlog that, once implemented, will simplify the work for future items. How to set up a continuous deployment pipeline, refactor parts of the product, or implement that automated import script. Cost can also be considered at the level of individual items, as development cost can outweigh priority, value, or risk;
- Trading conditions may change, requesting that some items be moved up or down in the Product Backlog;
- The cost of delayinfluences the classification. Donald Reinertsen considersthis is the cost of delaying the implementation of one feature over another;
Sameer Patil wrotea much longer postabout the various considerations that come into play when ordering the Product Backlog. The main takeaway from this is that the Product Backlog must be continually (re)ordered to maximize the value delivered in each Sprint. What is valuable depends on many contextual factors. Scrum does not and cannot offer a single technique for arriving at the best order.
tips
- As a Scrum Master, you can help a Product Owner arrive at an ideal order,asking powerful questions. “Which items help address the biggest assumptions we are making?”, “If I were to stop three sprints from now, which items would definitely need to be included?”, “If I could only keep 20% of the product portfolio, what items would you keep?” or "How can we optimize the classification to address dependencies?";
- the liberating structureminimum specification'can be used to help inform which Product Backlog items are absolutely critical to success and which are not;
- As a Scrum Master, help the Product Ownerfind alternative strategies to order the Product Backlog. Train the Product Owner to inspect the order frequently, based on insights that emerged during development;
- The Sprint Reviewit is an excellent opportunity to inspect and adjust the order of the Product Backlog with the Development Team and stakeholders;
closure
In this post, we break the myth that the Product Backlog is 'prioritized'. Although it is a seemingly trivial editorial change, the Product Backlog is "an ordered list". By framing the Product Backlog as a "priority list," we reduce the active role a Product Owner must play. He or she is responsible for continually (re)ordering the Product Backlog to maximize the value delivered in each Sprint as work progresses and ideas emerge. Finally, we offer some tips to help you understand the Product Backlog more broadly.
What do you think of this myth? Do you agree? What are your lessons learned?
Do you want to separate Scrum from the myths? join ourProfessional Scrum MasteroAdvanced Scrum Mastercourses (in Dutch or English). We guarantee a unique and revealing experience, 100% PowerPoint free, highly interactive and serious, but fun. Check out our public courses (Dutch) or contact us for in-house or English courses