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.