More specifically, I hate numbers or letter representations of priorities when it comes to product backlogs.

It’s a common strategy, even in Scrum. (Henrik Kniberg’s wonderful scrum book talks about a product backlog where higher priority items get higher priority numbers, preventing the “if this is critical and priority 0, what is ultra-critical? priority -1” issue.)

So why the hate? Simple – they do a lousy job of actually priortizing tasks. How many times have you encountered a product backlog where there were several items that were all of critical importance? How is this truly helpful?

Think of it in this way – what if half the items in your email inbox were of CRITICAL priority? At this point, what value does this tag add? At the end of the day, you’ll have to choose ONE thing to do next. What will it be?

I therefore argue that it’s exactly this hard decision that needs to be made earlier in the process, with the stakeholders who will wonder why this critical priority issue took precedence over that critical priority issue.

The real issue is that priority values attempt to apply a rigid metric of ABSOLUTE priority when the only thing that matters in the real world is RELATIVE priority – what do we do next? Even if you have the ability to complete work in parallel (e.g., more than one developer), you still need to figure out what those n people will do next.

Therefore, I propose that we kill the concept of priority values in the agile workplace.

Take your product backlog, remove the priority column, and sit down with the stakeholders. Don’t walk out of the meeting room until every item is sorted in order of relative priority.

The rest is easy: in your next sprint planning meeting, figure out how many story points you have available and work down from the top of the list. There are only two exceptions:

• When the developers believe that two pieces of work are similar enough to realize greater efficiencies if completed together. If this happens often, you need greater developer involvement in the priority setting meeting. 
• When the remaining story points don’t support the next priority item. For instance, suppose there are 3 remaining story points but the next item in the product backlog requires 5. It’s OK to scan down a little and take the next item at or below three points.

What do you think? What has worked well for you?