Product Backlog Ordering (Not Prioritization)

21 September 2012

Brent Reid
Raytheon

Traditionally, most systems used to track defects and work items on a development or maintenance program include the concept of priority. James O. Coplien addresses the topic of priority in his 2011 article "It's Ordered — Not Prioritized!"

I agree with Mr. Coplien that the product backlog should be ordered, not prioritized — and here I present slightly different reasoning to support the same conclusion.

Most prioritization schemes with which I am familiar have a discrete set of priority categories, or "buckets," in which items are placed. For example, an item may be prioritized as high, medium or low, or there may be a prioritization scheme of 1 to 10 (where items of priority 1 are of higher priority that items of priority 2, etc.). Regardless of the prioritization scheme, priority only has meaning within a context. For example, what is low priority today may be high priority tomorrow. Or, as high-priority items are removed from the list, other items are identified to take their place. On any given day, the highest-priority backlog items are worked. If a list of backlog items is prioritized only once, the high-priority items are completed first, then those of medium priority, and so on until all that's left are low-priority items. At this point, the prioritization scheme is of no value in helping to determine what needs to be worked next. Subsequently, the remaining items in the backlog are reprioritized based on what is known or remaining today.

I argue that items in a backlog are not prioritized; they're ranked in order based on contextual priorities. The priorities of a development program will determine the order in which tasks need to be completed. For example, imagine that there are two defects, both of which need to be fixed in order for the system to go operational. One defect, however, must be fixed for successful factory acceptance testing, while the other won't impact verification or integration activities until the product enters the site integration phase. Both may be equally significant from an operational perspective, but one needs to be fixed much sooner than the other in order to support the contractually defined program priorities, which change over time. As program priorities change, the ordering of the backlog may change. That does not imply that one item in the backlog is more severe or important than another item — it simply means that one item needs to be completed sooner than another in order for the program to meet its priorities.

In addition, Mr. Coplien states, "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."

If the program has competing priorities, the product owner must consider these priorities when ordering the product backlog. This places a heavy burden on him or her, but it also clearly places the responsibility of resolving the problem on the product owner instead of on the development team, which may not have a good understanding of these competing priorities.

Article Rating

Current rating: 0 (0 ratings)

Comments

Aaron Steele, CSM, 9/21/2012 1:03:03 PM
I had the same argument with James on this forum about this, but honestly, by the words you use, your argument is less potent than his.

"I argue that items in a backlog are not prioritized; they're ranked in order based on contextual priorities. The priorities of a development program will determine the order in which tasks need to be completed."

The definition of prioritized is "to list or rate (as projects or goals) in order of priority" - Merriam-Webster

That is exactly your definition! I agree that priority buckets have bastardized the correct usage of the word, but order does not give any weight to any one item. I can order things anyway I want, reverse priority, alphabetical, etc. That does not tell me which item to work first. If I had to chose another word, I would potentially use rank, but that again doesn't tell me urgency.
Bill Rinko-Gay, CSM, 9/24/2012 9:24:20 AM
I'm not sure focusing too much on semantics actually helps clarify the situation here. If the word "priority" is tripping people up we can lose it. At the end, what we mean to be doing is ensuring that the next task pulled provides the best incremental value for the incremental cost. That isn't necessarily the same as "return on investment" since some work reduces risk or cost rather than increasing revenue. But the goal is still the same. If management suddenly says, "Pencils down," I want to have achieved the best possible score on my test up to that time. (Thanks to Shawn Manley for the application of that analogy.)
Jon Innes, CSPO, 10/2/2012 8:44:18 PM
Good article. Regarding your last comment. I think as a community, we need to revisit our definition of ROI. An activity that reduces risk or cost can have a positive ROI without increasing revenue. I gave a talk on this last month at the San Francisco Bay ACM meeting (see http://t.co/b3ejma7O). Activities in Lean UX such as learning about product to market fit reduce risk and have can have an extremely high ROI. In fact there's a great Ignite talk http://t.co/l7cx3Pw4 about a prototype test that saved millions in development costs.
Robert Seres, CSM,CSPO, 10/3/2012 12:08:02 PM
I've seen terms like Backlog Organization, Grooming, Ordering, Prioritization (and even Ranking, unfortunately) used interchangeably by PO's, SM's, team members and on some rare instances by coaches without addressing the core issue you point out in the article. I think the focus should be on enabling a clear understanding of where each user story falls in the continuous sequence of work to be performed within a sprint/release. Whatever the terminology used, I believe the team(s) need to buy-in/agree to the utilization of a particular term.
Steve Hunton, CSM, 10/23/2012 2:49:00 AM
Much of the prioritisation and ordering can be removed by carefully reviewing and communicating with the team. Prior to sprint planning we have a sprint scouting exercise that looks closely at the backlog and the stories that are being prepped for the next sprint. By using senior developers we can help the Product Owner to fully understand what they're asking for and to understand where there needs to be any kind of ordering. If we identify that a particular story or stories need to be done in any particular order, one has a particular priority over another then we communicate that to the team. Otherwise, we have a single bucket for the next sprint into which all of the stories for that sprint go. The team then have the information about whether or not there is any ordering or priorities and the rest can be picked as they choose.
Duncan McCombie, CSM, 10/30/2012 11:49:27 AM
To me, the PB is a living, breathing, heaving, bleeding beast of opportunity. Priority/rank is never relevant to me, outside of Sprint Planning and I actively encourage (and get) the PO to poke and prod at it, ensuring - especially as Sprint Planning approaches - that the priorities of the business are reflected in the top-down ordering seen on the PB. This way, emergent needs and/or dependencies can be used to ensure appropriate engagement of The Team when the sprint starts.

You must Login or Signup to comment.