Get certified - Transform your world of work today


It's Ordered -- Not Prioritized!

3 August 2011

James Coplien
Gertrud and Cope

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, prioritization is only one technique — and rarely a good one at that. The new Scrum Guide instead uses the term ordered for the Product Backlog. This reflects 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 Team can discuss PBI ordering with the Product Owner but, in the end, the 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 some special occasions when you order the backlog by ROI priority, particularly when implementing advanced fixed-cost contracts for individual customers: see Change for Free and Money for Nothing. 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.4 (9 ratings)


Timothy Korson, CST,CALE,Educator,CSP,CSM,CSPO,REP, 8/3/2011 12:50:39 PM
Great article! The point is made clearly and succinctly. Vocabulary is important. Sloppy terminology goes hand and hand with sloppy thinking. It is good to see Scrum terminology being cleaned up.
Greg Della-Croce, CSM, 8/3/2011 2:01:04 PM
I find this article very helpful in many ways. However for me to put this into context of my small shop I would like to ask for a clarification. What form does a Product Backlog Item take? Is it a "product feature" or "User story"? The literature seems to use Feature and PBI interchangeably. This would imply that a Feature would have one or more Stories, and each Story would have a Definition of Done and Story Points. Is this a correct understanding?
James Coplien, CST,CSP,CSM,CSPO, 8/4/2011 1:03:54 AM
Scrum doesn't say. You're Agile; you'll figure it out. As for me, I use a mixture: use cases for the tough stuff (see and informal descriptions for much of the rest. But your mileage will vary. The whole point of Scrum is Kaizen, which means trying things out, measuring, and using your analysis to evolve toward the best. Scrum provides no final answers ΓÇö because there are none.
Michiel Buisman, CSM, 8/5/2011 4:37:42 AM
I would put up the roof first, if I were building a house for the first time and had limited time and budget. Most software development is really R&D: doing things for the first time. If I didn't put the roof first, I risk ending up with three walls, when time and budget run out. I would order the backlog on: which item would you really, really not want to drop of the backlog when the budget is gone. I suppose that woulde be ordering on "fear of loss" ;-)
James Coplien, CST,CSP,CSM,CSPO, 8/5/2011 4:58:44 AM
How would you put up the roof without some kind of supporting walls, or at least support posts? They are not part of the roof, and have value only in that they make the roof possible. The walls / posts have only indirect value; their intrinsic value is low. If you ordered by intrinsic value (which many have been equating with ROI and then treating as though it were a priority) you'd build a roof that was laying on the ground. It would have to sit there and wait while you poured the foundation and built the walls and the corner posts. That's inventory, which in Lean theory is muda.
Adrian Brae, CSM, 8/5/2011 5:57:33 AM
The 'support posts paradox' highlights another point: the engineering solution chosen and effort required for each new feature is often strongly dependent on backlog ordering.

If the roof-like structure is requested first (ie. A structure which will keep a specified area dry, assuming rain of x volume with winds of x velocity) you might get a solution with support posts - you might get a root built between two existing structures - you might get a helium balloon tethered to trees :)

Serious consideration must be given to the balance between immediate ROI and technical debt when ordering the backlog - We can think of it almost like the genetic code that grows a product - seemingly innocuous changes in story ordering might have dramatic effects on the resulting architecture.
Ed Blazejewski, CSM,CSPO, 8/5/2011 6:52:12 AM
I use this technique - Our sprint has a theme, we need to get certain feature(s) completed in this sprint, based on the theme. So out of a huge backlog we choose stories that help us accomplish the work based on the theme. That is our priority. Then we decide the order of execution of each story, based on that subset. i.e. some stories must be done last, others first, to help build the framework.
Stephen Berczuk, CSM, 8/5/2011 8:10:43 AM
While it's important to emphasize "The product owner must deliver a totally ordered Product Backlog" this isn't a new thing, and this is what I thought "prioritized" meant when I walked out of CSM training. The point about what rules you use to prioritize v order is interesting, and I need to think more about it, but it seems like having a definition of "priority" that leads to doing the "right" things first would fix that.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 8/5/2011 8:26:49 AM
It's good to see the Scrum Guide catching up with the real world. Old school Prioritization(stack ranking) was a rabbit hole too many Sprint Planning sessions went down and never came out. I used it once in 2003.
The options ordering provides allow us to organize and order PBI's based on the clarity of the business value; the agreement on how to technically deliver that value; and the acceptance criteria to be tested.
These allow us to better employ artifacts such as the Product Backlog Pyramid, User Story Mapping, and others that allow for multiple levels of granularity.
James Coplien, CST,CSP,CSM,CSPO, 8/5/2011 8:27:47 AM
Steve, I think that's what we've done. But re-defining English is often a bad idea, particularly when the language offers perfectly good ways to communicate the intent. So instead of re-defining English we just re-used a suitable and more correct English word. The English essence of the word "priority" implies the ability to do pairwise comparison between items, and that is not the essence of ordering a backlog for value.
James Coplien, CST,CSP,CSM,CSPO, 8/5/2011 8:32:59 AM
Mike ΓÇö Indeed, in Ken's podcast about the new Scrum Guide (, he says point blank that "We try to keep up with them." Good standards lag best practice by quite an interval (, just as progressive law lags social practice by as much as a generation.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 8/5/2011 11:33:59 AM
That is true James. And it causes me to wonder why we backed off the Release. Of all the topics folks come with to coaching and train, it is definitely in the top 3. It goes hand and glove with the "how do we get and plan budget? How do we work with the business planning and project management office, portfolio folks and regulatory people who want to see that you have thought about the path the business is taking.
All too often I see the last rites being given to dead scrum efforts because their success could not be communicated in business terms, particularly budget and delivery.
James Coplien, CST,CSP,CSM,CSPO, 8/5/2011 11:44:59 AM
I was less in on the discussions about release planning, but again, Ken's podcast is instructive. He affirms that Release Planning is a good idea. But he was concerned that if Scrum stipulated it, it would have to say something about how to do it ΓÇö e.g., how it related to the Product Backlog. A standard that just contains the three words "Do release planning" is not very helpful. But one that provides guidance can actually cause teams to feel constrained to doing things in a prescribed way. There are a million ways to do release planning and it's not the place of the Guide to stipulate any of them. That's the rationale behind its removal. But that shouldn't stop you from doing it ΓÇö don't ever feel limited by what the Guide says. Inspect and adapt.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 8/5/2011 2:54:54 PM
This is very helpful James as I plan to continue to do what is best for the teams I work with as they move to Agile and Scrum.
Perhaps in cases like this it would be good to ask practitioners, coaches and Trainers what their experiences have taught and then share that information.
Arne Åhlander, CST,CSP,CSM,CSPO, 8/8/2011 10:13:56 AM
Thanks for the article. I would like to add to the discussion by mentioning a book that has been a great inspiration to me when thinking about ordering, namely "SW by Numbers". In the book, ordering of MMFs (minimum marketable features) and AEs (Architectural Entities) are discussed. My understanding is that the "support posts" discussed above would qualify as AEs. In the book it is discussed how different MMFs might have different windows of opportunity. Some might be valuable before a certain date (Y2K), some might have value only after a certain date (when new laws or regulations are put into action), some might have other limitations in time. I recommend looking at ( for starters and also reading the book for inspiration.
Nis Holst, CSM, 8/10/2011 6:51:49 AM
Great... So for my 10 item PBL I only have to consider 3.628.800 different outcomes before deciding on the order? Damn… Business just came up with 5 new stories. This leaves me with 1.307.674.368.000 outcomes to consider... Better call my wife!!! ;-)

Great article James. I even think that I finally got the point (or did I? :-). Perhaps ArneΓÇÖs reference gives a solution to my PO nightmare above?
Joe Little, CST,CSP,CSM,CSPO, 8/11/2011 8:48:54 AM
Ordering the product backlog is, in the end, an intuitive decision.

We are trying to discover a host of things on multiple dimensions. Not least, a variant on the classic question that Freud asked "What do women want?", ours being "what will the customer really want when we release it?"

Discovery includes learning too, of course. And again, learning on multiple dimensions. My colleague Catherine Louis is very fond of emphasizing the importance of 'ordering' the learning.

Still, while we don't order PBIs based solely on Business Value per item, the PO is trying to optimize overall Business Value in some time dimension (let's say for simplicity of discussion, per release). (Yikes, the time dimension is yet another moving part.)

Nis makes a good point. Thus, the better the PO, the better he can 'review' all those permutations, and come up with a 'better' one quickly, so that his team can deliver the better iPad3 before those other guys deliver their next version. Yes, a difficult and important job. One can not imagine it ever being done if at any point in time we could define perfection.

Like others: From experience, I like user stories. I am not obsessed with them. Other formats work well for some teams, some situations.

I still find (maybe this is my sample set) that too many teams are ordering based (mainly) on technical dependencies. The team's 'efficiency' per se is NOT the most important thing to optimize, IMO. So, ordering by BV (almost solely) is often a big improvement (if they have at least a modicum of common sense).
James Coplien, CST,CSP,CSM,CSPO, 8/11/2011 9:33:02 AM
HI, Joe ΓÇö I think that a key insight that is closely related to the change is that business value is not a function of a PBI. It is a function of a traversal of the Product Backlog to the depth of a given PBI. The point is that ordering is everything.

PBIs rarely have any stable, static ROI worthy of consideration, that holds independent of the PBI's relative backlog position. So ordering by incremental (per-PBI) business value is a dodgy exercise. You compare the ROI of two items on the backlog, use your judgment about how to move them, and you do so to get higher value and voila! you find that moving them causes their values to change. That means that you can't reliably use fixed ROI values on a PBI as ordering criteria. Doing so is just a form of prioritization: a prioritization based on incremental ROI. It doesn't work because of this problem that moving the PBIs changes the criteria for moving them. Therefore, in general, the ordering must be broader than a priority ordering, and you need to consider value of the backlog as a whole, taking the relationship between PBIs, and release dates, into account.
Thomas Moedl, CSPO, 8/12/2011 1:47:43 AM
Thank you for that important distinction, the ROI is definitely a long-term result of the total backlog ordering.
I like the tropical rain roof example, as I usually use the cellar/living room analogy to explain this: it clearly does not make sense to postpone the cellar implementation by assigning a lower priority to it.
In general, we are employing a goal hierarchy along with goal contribution modeling, similar to goal-oriented requirements engineering by Axel van Lamsweerde.

Besides: What do you mean by "The Team must take PBIs in Product Backlog order"? Doesn't that mean the team is forced to pull? I mean: isn't that eventually push? One of my best experiences with Scrum is exactly, that badly-written specifications end up as an impediment rather than burdening a project for a long time.
James Coplien, CST,CSP,CSM,CSPO, 8/12/2011 4:02:03 AM
Hi Thomas! Your comments and references add good texture to the central point.

The point of ordering the backlog is to stipulate the order in which the market will see them. And, yes, that is a form of control by the PO. Let's be clear: the PO has the final authority over the order. But I differentiate that from pull versus push. Lining up the cars on a train is one activity. Whether I pull those cars, or push them, is a completely separate consideration than the ordering.

Scrum doesn't fix a lot of problems, but provides a framework for making problems visible. The principle of Enabling Specifications ( gives the team the power to "go to the beach" if the PO doesn't do his or her job. That makes the problem visible so that the Scrum Team can fix it. Pointing out bad PBIs as items on the impediment list leads to improvement, so bad specs don't become a long-term burden.

Thorsten Søbirk, CSM, 8/12/2011 4:26:45 AM
Perhaps a silly question: where is this Scrum Guide available? Could someone post a link please?

Also, other content needs to be updated too. For instance still consistently says "prioritized".
James Coplien, CST,CSP,CSM,CSPO, 8/12/2011 7:35:47 AM
Not a silly question, Thorsten. The Scrum Guide, which is edited by Jeff Sutherland and Ken Schwaber with support from David Starr and myself, is what Ken and Jeff consider to be the formal definition of Scrum. You can find it at The English version is current and I think some of the other translations have also been brought up to date, while others will doubtless take some time. Trainers are updating their materials as they see fit, and I trust that the ScrumAlliance materials will eventually come more in line with the Scrum definition.
Thorsten Søbirk, CSM, 8/14/2011 11:46:35 PM
Thanks James!
Michael James, CST,CSP,CSM,CSPO,REP, 8/17/2011 3:27:13 PM
I agree with Michiel Buisman; I'd build the roof first. Fortunately, teams are learning to build software without the tight coupling and dependencies inherent in physical construction. So I'm surprised we're still using the old house analogy in the year 2011.

A house is necessarily built in unchangeable horizontal layers that depend on each other. A house doesn't deliver any business value to users until it's close to completion. This is a limiting way to think about software.

James Coplien, CST,CSP,CSM,CSPO, 8/17/2011 3:48:31 PM
Some of the core inspirations behind Scrum are based on the principles of the Toyota Way (not on Lean, which was a separate, parallel development). To build the roof first violates a central Lean tenet: Don't create inventory. I have several clients who think like you and they have megabytes of "roof" code built on speculation, waiting for the walls and foundations that sometimes never come. It sometimes goes under the term "technical debt" ΓÇö and it can be a life-and-death decision for an enterprise.

I'm happy to use a better example and I have many real-life examples from individual clients; however, they are not accessible to the average software developer. And I have clients who are using Scrum to build everything from bicycles to, indeed, houses. We explored these principles in sessions of IKT-Agil in Denmark which involved both software and architectural firms. They understand these examples. Most people do ΓÇö because most people, even in 2011, still live in houses. Good metaphors are part of being a good teacher. Translating them to the real world is the job of a good practitioner.

If you believe that a house doesn't deliver business value until it's close to completion, I commend the writings of Christopher Alexander to you. He points out how modern house construction has fallen victim to the waste of investment economics and that good houses in most cultures in the world are build incrementally, through piecemeal growth and local adaptation. Master-planned Western models somehow go hand-in-hand with the fact that countries like the U.S. use a quarter of the world's resources but represent only 5% of its population. Scrum at its foundations is about a greater degree of social responsibility than that.

Historically, you'll find the same roots beneath Scrum and Alexander's ideas. So even though the example is simple, it drives to some core principles ΓÇö principles so simple that they show through in this metaphor.
Michael James, CST,CSP,CSM,CSPO,REP, 8/17/2011 5:17:38 PM
I guess this wasn't explicit enough: If the user's real need is a roof, I'd build a shippable, usable roof first, and as little of the other stuff as necessary to have the roof start producing value for its users and feedback to its developers about what a better roof might be. This is not practical in the physical world, but becoming more practical in the software world, partly driven by Scrum/Agile's emphasis on doing the top priority things first. If the user's top priority is the roof, the "inventory" in this analogy is the foundation, scaffolding, plumbing, blueprints, walls, etc. That doesn't mean we don't need some of that inventory, it means we find ways to deliver value with as little of that as possible. Organizations that strive meet the user's top priority needs first will learn the most about those needs first. These principles will remain the same whether or not you convince people to accept this change to Scrum's definitions. --mj
James Coplien, CST,CSP,CSM,CSPO, 8/18/2011 3:18:34 AM
Ah: The key here is "the other stuff as necessary to have the roof start producing value." The other stuff may be a wall or corner support and, at this time, has less intrinsic value than the roof. So your example directly makes my point. Thanks for clarifying it for those who don't yet understand.
Cristina Tudose, CSM, 8/19/2011 3:05:44 PM
I guess after all will be so many revisions of this Scrum process that we will go back to waterfall eventually.

Back to the basics, like Einstein said "I don't know what kind of weapons will be used in the third world war, assuming there will be a third world war. But I can tell you what the fourth world war will be fought with -- stone clubs."
Ashish Parmar, CSM, 8/22/2011 6:09:30 AM
I believe that the priority of the product delivery as understood and defined by the end client also plays a key role in how the Scrum Master and PO order and prioritize the items in the PBL to have a positive ROI, both for the team and also the end client. I see both ordering as well as prioritizing an intrinsic part of the defining the backlog and the two terms cannot be exchanged or replaced with other. Meeting with the end client to understand the requirement will lead to defining the entire product backlog. From this backlog, again based on the meeting with the client, backlog items need to be prioritized to define what is of most value to the client. Based on the priority list generated, order the sequence in which the product will be delivered at the end of sequence.
Michael James, CST,CSP,CSM,CSPO,REP, 8/22/2011 8:59:59 AM
Here are two trends larger than Scrum: the primacy of user value in prioritizing work, and the discovery that perceived dependencies tend to evaporate as we learn new ways of working that deemphasize them. Our code, and even our beloved architecture, are all just a means to the end of delivering value. They can be changed (if we do our work right) as we iterate to discover our users real needs. To Cristina's observation about versionitis, gratuitous changes to Scrum's definitions make Scrum (and especially Scrum dot org) less relevant in this larger movement. --mj
James Coplien, CST,CSP,CSM,CSPO, 8/22/2011 12:22:35 PM
Michael, maybe it's just me, but I read this as a political shot at This update to the Scrum Guide has nothing to do with ΓÇö why did you bring it into the discussion? This isn't the place or time to hone a political agenda. These changes were agreed by Jeff Sutherland and Ken Schwaber. They are the inventors of Scrum, and your concern with their articulation of Scrum should be on the basis of the merits of the ideas rather than political history. If you have an issue with their ownership of Scrum you can take it up with them.
Clinton Keith, CST,CSP,CSM,CSPO,REP, 8/22/2011 8:36:09 PM
I understand the reasoning behind the desire to change the term to "ordered" instead of "prioritized". I think any good trainer is going to teach that the backlog has to take other parameters than delivered value into account when prioritizing/ordering the PB.

However, the reason I don't use the term ordering is the implied permission it gives to step too far back from the importance of delivered value that I feel it implies. After all, a BDUF is a form of PB that is ordered according to things like "resources" and "perceived architecture/infrastructure". Indeed the use of the building analogy supports that. Building a house cannot be compared to the complexity of new products. This type of analogy (and assembly line approaches) led us down the waterfall path to begin with.

The biggest problem we have right now is the half-steps organizations take in the adoption of Scrum (e.g. Scrumbutt). Using "ordering" over "prioritization", IMO, gives another bullet to the inertia we are trying to overcome.

Thanks for submitting the article James!
Nigel Baker, CST,Educator,CSP,CSM,CSPO,REP, 8/25/2011 7:10:44 AM
We don't build houses. Let's kick these housing metaphors to the curb, where they deserve to be.

I took ten seconds to go to to look up some definitions of words.

pri┬╖or┬╖i┬╖tize verb
\prī-ˈȯr-ə-ˌtīz, -ˈär-; ˈprī-ə-rə-\

Definition of PRIORITIZE

transitive verb

to list or rate (as projects or goals) in order of priority

Definition of PRIORITY

: superiority in rank, position, or privilege
: a preferential rating; especially : one that allocates rights to goods and services usually in limited supply <that>
3: something given or meriting attention before competing alternatives

The dictionary description sounds like exactly what we do with Product Backlogs. Important things first. It does not assume that is "highest business value" things first. That is an assumption. I do not see a need for a new word. If I had to chose a new word, I wouldn't choose "ordered". It could allow a very "waterfally" or constructionist Product Backlog to exist.

Lovely discussion point though - Thanks for putting the thinking out there James.

Personally, I do hope these words get reversed in the next edition and perhaps a little more community outreach on the guide. I know Ken know seems to dislike a lot of us, but I think he does Scrum a disservice by not reaching out with his guides.
James Coplien, CST,CSP,CSM,CSPO, 8/29/2011 3:31:28 AM
Maybe you don't build houses, but I have been working with folks the past few years who have morning standups, a product backlog, a product owner, a ScrumMaster, and several teams who *are* building houses. And, as I said, it's an accessible example. I'm doing research now to gather data on an example much closer to home for you, and I think you'll see why a Product Backlog operationally is not prioritized. Stay tuned. (Or do your own research. At least this change was based on some concrete analysis. We don't have enough of that in any of the Scrum forums ΓÇö I don't recall having seen any at all ΓÇö and we have too much blah blah blah. So I'm looking forward to your research results, too.)
Mario E Moreira, CSM, 9/3/2011 10:21:57 AM
Great discussion! While I do believe in ordering, it is coupled with dependent stories and also the business objectives. Dependent stories help you understand what has to be there in order for something else to work (or you know to stub it out). Business objectives helps because this is typically where the ROI gets discussed (vs individual stories). However, stories should be linked to the business objectives (with ROI info) you are building for so this can help in ordering.
Mario E Moreira, CSM, 9/3/2011 10:21:59 AM
Great discussion! While I do believe in ordering, it is coupled with dependent stories and also the business objectives. Dependent stories help you understand what has to be there in order for something else to work (or you know to stub it out). Business objectives helps because this is typically where the ROI gets discussed (vs individual stories). However, stories should be linked to the business objectives (with ROI info) you are building for so this can help in ordering.
James Coplien, CST,CSP,CSM,CSPO, 9/3/2011 11:48:06 AM
I agree. (Except they aren't stories ΓÇö but that's another story.) These ideas are so important that it's worth saying twice :-)
Michael James, CST,CSP,CSM,CSPO,REP, 9/3/2011 10:36:13 PM
Indeed, they're Product Backlog Items. At least we're together on that. --mj
Doug Shimp, CST,CSP,CSD,CSM,CSPO,REP, 9/7/2011 10:28:25 PM
Interesting read but, I don't see the distinction as relevant. Order vs. prioritize "Priorities drive pair-wise comparisons (by English language definition)"

The definition from Marion Webster is
3: something given or meriting attention before competing alternatives

The definition above does not necessitate pair wise comparison. That is a choice of which analysis technique to use.

There are many techniques for analysis.

The way I look at it is "what you focus on matters. What you focus on next is where the team's energy will follow. The PO focuses the teams energy on Next." Priority is a good word for that. Order seems soft and fuzzily abstract which is a problem in our 'process culture' language in general. I see the guidance suggested by the word prioritize to be more clear and purposeful.

One bite at a time. Create a flow.

Also the following statement locks me up when I read it... 'consider the entire backlog when ordering PBIs' .... 'totally ordered'

It feels like all, every, only, completely, etc. this is too ABSOLUTE for complex work.

Absolute language works for smaller more predictive problems but, many of the backlogs I encounter can only be known in partiality and the granularity is not uniform. Much of the time we are simply looking for a place that we can move on next. We stabilize a known center and work outwards. Just like writing the use cases referenced above. Write the main success scenario and then work your way down into more detail until you have sufficient detail for your product's purpose. I like use cases and have taught and used them for years. Use Cases are powerful tools to stabilize and understand big piles of behavior however, there are always bigger piles.

Work from a known center.

BTW - I have built houses and painted many of them and anyone who has had to restore a Frank Loyd Write special (found in good ole Racine, WI my home town) knows that house restoration/building can get very interesting (not predictive) very fast. All of those analogies we use are relevant but, like all MODELS they are not reality just tools we use to interpret reality.

Don't make a belief out of your model.

Based on what I have read above. I still favor PRIORITY over the word order.
Mike Beedle, CST,CSP,CSM,CSPO,REP, 9/8/2011 5:26:07 PM
Technical prioritization will always include some comparison by pairs, because even in weighted prioritization algorithm, you will eventually involve a comparison of two items. For example, if I want to compute priority with a weighted prioritization algorithm to know what stocks symbols I should trade first because they have a higher probability of producing better trades, and I know their different technical attributes, fundamental values and economic values that effect them, I could compute a weighted priority of the symbol list using some or all of their attributes, and then prioritize the weighted sum (by comparison of pairs). Even if you prioritize by one attribute first (comparing pairs), and then prioritize again by a second attribute (comparing by pairs), you will have to prioritize using pair comparisons. On the other hand, in the end, you would consider or analyze *every element* of the list, and therefore, you can order an entire list ΓÇô it doesnΓÇÖt matter how large it is, with or without a weighted prioritization algorithm. So prioritization does guarantee taking in consideration the entire list.
But to me where Jim is really right, is in saying that we donΓÇÖt ΓÇ£guarantee priorityΓÇ¥ ΓÇô some items might just be ordered or sequenced, that were not compared to many other items. For example, I often add filler PBIs to Sprints to match capacity. These items do not come in priority necessarily as they may be chosen because they have ΓÇ£the right sizeΓÇ¥, they are low-hanging fruits, even if they are ΓÇ£want to haveΓÇ¥ or ΓÇ£nice to haveΓÇ¥ instead of a ΓÇ£must haveΓÇ¥. Some items are ordered by priority ΓÇô some are not. That makes the backlog ΓÇ£partially prioritizedΓÇ¥, and while ordered seems more technically accurate, there is definitely at least ΓÇ£partial prioritizationΓÇ¥.
Is the glass half-full, or half-empty? In other words is it enough for the Product Backlog to be ΓÇ£partially prioritizedΓÇ¥ to call it prioritized, or is it better to call it ordered to be more technically correct. While I have to confess I am also lazy to change all my documents and presentations to ΓÇ£orderΓÇ¥ from ΓÇ£priorityΓÇ¥, I am having nightmare just thinking about how to explain this ΓÇ£subtle differenceΓÇ¥ to the students in my CSM or CSPO classes.
Going back to a less technical and more human perspective, in everyday language and going by the dictionary definition: , priority is more emphatic than ordering because priority conveys more urgency and ranking than ordering. It is a half truth, however.
Nilay Coşkun Yener, CSM, 9/13/2011 3:31:21 AM
What are the other techniques for ordering all but prioritization ?
Thomas Weingartner, CSM, 11/10/2011 12:57:28 PM
I completely agree with the usage of ordering instead of priority. People, especially marketing people, around me usually think in priorities high-medium-low or must have-desirable-nice to have and they end up with a lot of high/must have items and never commit to which ones should be implemented first, since they are not forced to.
Note: We're not Scrum yet.
Philip Lewis, CSM, 11/17/2011 1:36:51 AM
An interesting article. I agree that ordered may seem more correct than prioritized, but business people are very used to using the priority, so some flexibility in terms is always going to happen around this.

For me, this invokes thoughts around dependencies and how they are managed in Scrum. Clearly in big projects there are technical or other dependencies which will naturally direct the order in which things need to be done. "Roof is built after walls" in the example above seems to be one of those. But for Scrum, where User Stories are independent of each other by definition, the order in which things can happen may be less clear. Also, we deliver potentially shippable products along the way. In the "Roof" example, I would expect Scrum to evolve the solution over Sprints, so would not be surprised to find an umbrella or a gortex jacket along the way..... I'd be interest to hear the thoughts of others on this....
James Coplien, CST,CSP,CSM,CSPO, 11/17/2011 4:15:12 AM
Scrum doesn't have user stories, so I don't know how there can be any definition of them being independent in Scrum. And as for the way business people think, Scrum is all about changing that. But, yes, if you need an umbrella along the way ΓÇö because the PO thinks it adds value ΓÇö that's fine. It is a good example of ordering. No homeowner in their right mind would say that having an umbrella is more important (higher priority) than having a roof. A prospective homeowner would likely agree that an umbrella had high interim value for some timing and ordering of deliveries.
Fabrice Aimetti, CSM,CSPO, 11/22/2011 10:51:54 AM
Hello Jim,
By the way, I translated into french your paper :
Regards, Fabrice
Bhargav Pradhan, CSM, 12/1/2011 1:13:42 AM
if "Priority" is just one of the techniques for backlog order, are there any others?
James Coplien, CST,CSP,CSM,CSPO, 12/1/2011 4:11:00 AM
Hi, Bhragav. Please follow some of the links in the article. One thing you can do is to order the backlog by incremental ROI ΓÇö that optimizes the strategy of aborting development when financial targets have been met. Another is to arrange all the items on the backlog to give the highest long-term ROI: it may make sense to defer a high-priority item to take advantage of emergent market conditions. Another is ordering by market segment. Another is ordering by market segment and season for seasonal products. You're a good Scrum person, so you know that Scrum provides no final answers. I am sure you can imagine dozens more. If you can't, ask your product owner. That's their job.
Hazurasingh Siviya, CSM, 12/7/2011 4:47:00 PM
Excellent article. I have observed the emphasis on priority thus looking at detailed stories, relative values etc while loosing site of the bigger picture, be it from enginnering and integration stand point (like the example of having roof without walls!!!). I think it makes sense to have a look at the bigger picture (including what makes sense to have in place for certain items of value to be delivered) while ordering the Product backlog. Thanks James for bringing out this perspective very clearly.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 12/16/2011 11:35:58 AM
I stopped by to see what was new and saw you too have worked with people who build real things. My experience was with Hal MacComber and was blown away how proactive and aggressive 'real developers, architects, and designers are at implementing scrum and agile. maybe it is because they have real budgets, real deadlines, and real penalties if the miss.
James Coplien, CST,CSP,CSM,CSPO, 12/16/2011 11:39:46 AM
Interesting experience. Yup, I too am up to my ankles, head-first, in real-world stuff. But most of the time I don't find "aggressive" and "Scrum and Agile" going together. True to Scrum's roots, my partners are getting better at harmonizing than at fighting. That's how it should be, I think.
Mike Dwyer, CST,CSP,CSM,CSPO,REP, 12/16/2011 11:44:51 AM
Speaking of real, I would suggest that we do so with releases, backlogs, organizing and delivery. Too often I see these conversation go off into the land of theory and theology - exactly the opposite direction the Scrum and Agile journey began.
Gang, it is all about DELIVERY of product functionality that has value to the PO, it is not about and never should be about HOW elegantly or coolly and definitely not about it being done PERFECTLY'the right way'. Try adding in the word 'viable' to all of the above. It moves you back to the goal what many of us who do Scrum and Agile work toward, the delivery of working, valued, product.
James Coplien, CST,CSP,CSM,CSPO, 12/16/2011 11:46:17 AM
Maybe you should take this up in an article of your own here.
Aaron Steele, CSM, 1/14/2012 3:50:58 PM
I would have to voice my opinion as one of the disappointed, in terms of both the choice and rationale around this change. The move to "ordered" from "prioritized" seems like a backwards movement to me. Definition 1 of prioritize "to organize (things) so that the most important thing is done or dealt with first" seems to fit with exactly what we want to be doing. The definition of "most important" is where the flexibility lies. One could assume a net present ROI when determining that distinction, or some other means of declaring it most needed at the time. Ordered does not necessarily make this distinction as by definition, there also needs to be a "rule" associated to the arrangement. I could technically order by feature, user, etc. and not necessarily want those things completed in "order". If priority seemed to not meet the original goal, I would have chosen something like "sequenced" or "ranked" instead which is at least somewhat more inclined to promote doing something before something else.

In terms of the "roof" argument, I tend to agree with it not being a relevant example on many levels. In my opinion, "roof" is a technical implementation or task, not a goal or need. No user "wants" a roof, they want shelter from the elements or shade, or some aesthetic object, i.e. "As an individual, I want shelter from the wind and rain, so I can live a long happy life.", but most people just want a house. A roof is a task to create the house, a roof nor walls, nor foundation provide any value by themselves per say. Just one man's humble opinion.
James Coplien, CST,CSP,CSM,CSPO, 1/14/2012 5:26:25 PM
The new wording allows you to order by priority. We thought that there might be people other than you who don't want to be told how to order, and who take the big picture of overall value that arises from the right sequence of PBIs rather than giving in to the tyrrany of the urgent (see earlier posts). While "house" can be a distant PBI, near-term PBIs must be broken down. The ordering of those broken-down PBIs is crucial to value, and has little to do with their individual priority. To focus only on the house is a bit naive, but, yes: it is common in some management approaches. Waterfall is one of them, focusing on a single integrated whole many months hence. That is neither Agile nor considerate. At the level of individual items, the word "priority" caters to those who want a quick pop rather than soberly considering long-term consequences, and to those who still believe that "Agile" means "fast." So while I'm disappointed in this posture, we allow you to give in to your perspective. It's quite a stretch to use it to do waterfall as you propose for the house, or to give into today's urge as one can infer, but if you can justify it (not that you have), Scrum is broad enough to accommodate you.
Aaron Steele, CSM, 1/15/2012 1:22:31 PM
Priority is simply precedence, not urgency or a "quick pop" (although in some cases urgent should take priority and/or precedence). I would hope that projects/products have POs that take a net present value/ROI approach to prioritization. In the end, I think the idea is the same, but backing off of a more concrete definition on this (as well as moving away from "commitments" during sprint planning) seems to water down the framework, IMHO.

As fas as the house, I suppose it depends on what you are considering the house. If a house is only 4 walls and a roof (say the underlying architecture that can be built off of), then I would disagree that its naive, but would agree if it is the completed project with carpet and railings, and everything else. 4 walls and a roof by themself do not provide anything (as you mentioned, a completed roof would be inventory without the walls, as would the walls without the roof).
James Coplien, CST,CSP,CSM,CSPO, 1/15/2012 5:10:02 PM
Priority is not about precedence in time; it is about importance. Please refer to your own former post. Product Backlogs, on the other hand, are about time precedence ΓÇö ordering. While many here would say that the above description is an unsuitable example because it is a house, I think it shows a misunderstanding of the deeper parts of Scrum. I can send you a paper from Rolf Simonsen from Technical University of Denmark describing how one of the largest construction firms here uses what they call Lean Construction. It's Scrum, replete with backlogs, fixed-length sprints and stand-up meetings. Where your analysis falls down is in inventory management along the value stream. The PO is responsible for just-in-time delivery of components ΓÇö crucial when the site space is small, and in any case important to reducing the cost of inventory while reducing work in progress. You're focused on the demand side (and still, I think, at the wrong granularity) but the supply side is equally or more important. It wouldn't matter if the house were a gestalt that goes up in a day, but for a process that unfolds over several weeks, it matters. Another place where your analysis falls down is in its claim that a completed roof would be inventory without the walls ΓÇö I recently saw a project in Helsing├╕r where the roof was erected first to give shelter for the subsequent work on the lower structures. Or see with its own repercussions for ROI. To supplant proper ordering with prioritization doesn't water down the framework (except for those who want to be told what to do) but makes it more broadly effective. While in the past people were doing priority ordering, Jeff Sutherland has noted that people can double their ROI by re-ordering their backlogs. Prioritization is for the non-thinking team, and while it won't kill you, it doesn't reflect Kaizen mind. Ordering for value is what Scrum is about.
Aaron Steele, CSM, 1/16/2012 7:39:05 AM
Priority is absolutely 100% about time. The root prior is explicitly defined as being earlier in time. Order by itself has zero time context. That being said, to not bore the rest of the community, my final thoughts on the subject:
1. I think you last statement is perfect, and I think we are both arguing the same, just with different words (which can obviously be argued)
2. I would love to see the paper. I don't disagree that Lean is a very viable way to develop in both manufacturing and software
3. I would agree that I do focus on the delivery side, and think that there is no real "value" on the supply side until it is delivered (again another area I'm sure could be argued fully :) )
4. The roof is a great example. It went up first because it provided a different but deliverable value from its final use
5. I completely disagree that Prioritization is for non-thinkers, I think it makes them have to think harder with inputs from the entire team to help with that specific ordering (again we don't obviously agree on that definition)
Overall, thanks for a great discussion and look forward to reading more of your articles.
Bruno Eduardo Andrade de Carvalho, CSM, 5/7/2012 1:00:10 PM
Very good article!
Matt Curtin, CSM, 11/27/2012 10:00:08 AM
Great article! I like to use the KANO Model Must Have, Satisfiers, Delighters, Dissatisfies to represent value to the customer. The backlog is then "Ordered" as a result of release planning. In some cases a Must Have, like walls, must go before the delighter, the roof. At the end of the day the roof is what we really want and we can build it first but it's not functional without the walls. It's the idea of MMF Minimally Marketable Feature right?
Mudduluru Gajendra Varma, CSM, 2/26/2013 2:21:35 AM
The Prioritization is not just doing based on the ROI, there will other considerations like risk of the PBI if we won't complete it for particular product because of the technical demand/challenges. In my view both prioritization and ordering are in same meaning. While doing it, what are the considerations you have are most important. These are depends on the type of project that we are executing. Considerations would change based on type of project and kind of competition in the market.
Steve Carter, CSM, 4/24/2013 4:24:10 AM
I found myself getting annoyed with this article because it deprecates using "priority" and advocates "ordering" but then is itself confused by what "priority" means.

I agree that ordering is a better term than priority though. One point that the article makes, a little buried in the text, is that product backlog must be *totally ordered*. This means no two stories share a position in the backlog. This is explicit in the scrum primer I believe, but "ordering" helps this subtle distinction to stay alive when communicating with those who are less engaged in making Scrum work.

For me, priority means prior + ity, that is, first + ness.

That's all. I had to learn that you can't share priorities when working for a boss who only ever gave out top priority tasks.

But I suppose in others the concept of priority might be confounded with concepts of urgency or perceived risk.
James Coplien, CST,CSP,CSM,CSPO, 4/24/2013 4:12:42 PM
Glad you came to the right conclusion, but I am perplexed by your expression of confusion about priority. I think the article is consistent and takes such use directly from canonical English as one can substantiate with any dictionary. As someone who is regarded as a pretty good writer and who used to teach English composition I stand my ground.
Eddie Caplan, CSM,CSPO, 10/28/2015 9:27:21 AM
Ultimately, prioritization and ordering leads into a schedule. In other words, a team member can only do one thing "now" and afterwards will reevaluate what is the NEXT thing to "do now".

To that end, prioritization is a step TOWARDS the deciding what to do "now". Ordering is a more refined step. The schedule (what to do now) is the last step.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up