Ordered Not Prioritized
"Prioritizing" has been removed in favor of "ordering" as the term for organizing the Product Backlog. Ken and Jeff asked Jim Coplien to elaborate on the reason for this change:
In the past, the Scrum Guide consistently used the word "priority" for the Product Backlog or noted that the Product Backlog was “prioritized.” While the Product Backlog must be ordered, ordering by priority is only one many techniques — and rarely the best one at that. The new Scrum Guide instead uses the term ordered for the Product Backlog. This reflects a long-held understanding by many leaders in the Scrum community. Let’s clarify the reason for the change.
To prioritize a list means to order its items by their importance relative to each other. Priorities drive pair-wise comparisons (by English language definition) of items on the list. Think of using bubble sort to prioritize the Product Backlog: compare the top two items and interchange them if they’re in the wrong order, and then move on to the next pair, and keep cycling through the list until everything is in its place. Prioritization and sorting go hand in hand. All the comparisons are local. This process is analogous to local optimization.
More broadly, the Scrum Team and the Product Owner in particular need to consider the entire backlog when ordering PBIs, to optimize value or ROI. Most people commonly think of ROI as the priority; however, you need to think of ROI as a long-term result of the total backlog ordering rather than just the sum of the ROI of individual items. This is true in part because the ROI of an individual item depends on its position in the backlog. Let’s say that you have a PBI to put dancing Santa Clause figures on the welcome screen to a web site. That item will lead to some ROI in late November and during December, but much less ROI in July or even in the ensuing January. Moving the item on the backlog changes its ROI (or, more generally, any such per-item ordering criterion), because re-positioning it changes its release date. Even the shifts caused by bubble sort would cause the PBIs’ “priority” to change as a side effect of prioritization itself.
The Product Backlog indeed must be ordered: its ordering determines PBIs’ order of delivery. The Development Team can discuss PBI ordering with the Product Owner but, in the end, the Development Team must take PBIs in Product Backlog order. However, the Product Backlog is not guaranteed to represent an ordering of PBIs by either value or priority. You can’t just assign priorities to PBIs — whether they come from ROI or importance to the business or anywhere else — and then prioritize the backlog on the basis of those relative values. You must consider the entire backlog of PBIs together.
Let’s say you’re building a house in the tropics, with your main reason being to keep off the afternoon rain that comes every day. You envision a house with walls, windows, and doors, but it’s really the roof that you’re after. You build a Product Backlog for your house. Would you put the roof first? That would be a prioritized backlog. What you do is to order the backlog to yield the highest long-term ROI. (The same principles also apply to short-term ROI, for what it’s worth.) To do so takes deep knowledge of the business, knowledge of business, market, and engineering dependencies between PBIs, knowledge of evolving market windows and market conditions, the state of the supply chain, and a host of other details that are much more complex than anything like bubble sort can accommodate.
To use the term “ordering” instead of “prioritization” also makes it clear that the Product Owner must make decisions. He or she cannot just say “These five items are all priority 1; these three items are priority 2” and so forth. The Product Owner must deliver a totally ordered Product Backlog.
Of course, you can use prioritization as the ordering technique because prioritization is but one form of ordering. Ordering PBIs by their "priority" leads to suboptimal market value and reduced ROI. Jeff Sutherland has often said that you can double ROI by reordering the backlog. Usually, the best orderings are not priority orderings. There are exceptions and some special occasions when you order the backlog by ROI priority, particularly when implementing advanced fixed-cost contracts for individual customers. However, those are highly contextualized techniques for single customers with fixed-cost (and sometimes fixed-scope) contracts. They do not apply universally, and the Scrum Guide does not and should not stipulate their use — nor the prioritization necessary to support them. More generally, you will use a non-prioritized ordering. Inspect and adapt.