Setting priorities is hard. When a customer is asked to number 10 items with priority 1-10 it often ends up with one 10, two 5s and seven number 1. That usually means that there is one item that isn’t worth doing at all (the number 10), two items that are nice-to-have (the number 5s) and seven items that are really needed.
When coding, one thing should be done at a time. Trying to get everything started at once and multitasking is just inefficient. When given items that are “prioritized” like the above example the order in which to do things has to be defined.
In one project I worked in the managers actually made a priority like this. To refine it they then set letters to distinguish between the number one priorities. I even think they got as far as introducing another number, to distinguish between the different items with priority 1a, giving priority 1a1 and priority 1a2…
That’s ridiculous. When setting priorities I have a simple rule to the top priority:
The Ordered Index Cards
A better solution than the 1a1 and 1a2 priority levels is to use index cards for backlog items. In one project I printed the entire product backlog (it was about 50 items) on A5 sized papers and ask the managers to participate in a workshop. I presented a single item at a time and then asked the managers to arrange the index cards in one single row on the conference room table. At first they were a bit reluctant to participate but after a while everyone was heavily engaged, arguing about priorities and comparing items against each other at the top priority end of the table.
When I left the room I actually had 50 items ordered number 1 to 50. It worked.
The Dice Threat
When everything else fails to get the customer to produce a priority I use the dice threat.
You say that those six items are exactly equally important and prioritized. Tomorrow I’ll bring a dice to decide what item to start with.
Given that option it is astonishing how fast the customer can pick out a single item that should be done first…
When Several Items are Really Number One
To be honest, there are cases where there are several items that are number one together. The prime example is the core features that are true “must have” to be able to do a release. Without them, the product would be useless.
In those cases other factors should be used to decide priority, such as risk reduction. Always try to address the item with the highest risk first.
Priority vs. Order of Implementation
Even if the customer does manage to produce a strict order of priority it is not always the best order of implementation. I do want the customer to have strict priority order to the backlog, but when planning the work in the team I let a number of factors decide which one we do first. I prefer to handle risk early. I prefer to get large tasks that can’t be split on several people started in time. I prefer to get the things that only one person has the right competence for out of the way.
Getting a Priority
The priority is not the only parameter deciding the order of implementation, but it is the single most important. I’m trying to be careful to always get prioritized items from the customer. I even insist on getting a strict order, not one where everything is the top number one priority.