A prioritized list of work items is a key artifact of any Agile development process. Take a SCRUM Project Backlog or eXtreme Programming User Stories as examples. Armed with such lists, the development team will be working on the most important tasks at any given time.
The problem, however, is that assigning priorities to real tasks on a real projects doesn’t follow a simple recipe. The act of prioritizing is the art of prioritizing. And as with any art, there are always tips and tricks. I will share a few from my experience.
Before We Plunge
I assume that a “collection” of items and a “time estimation” are already done. We have produced the list is of items with rough estimations waiting to be prioritized. I recommend a brisk borders between “Collection”, “Estimation” and “Prioritization” stages. Have the “collection” and “estimation” sessions officially “closed”, switch to “prioritizing”. Don’t let the talk to drop back until we have the priorities done.
The default strategy a project owner tends to take is “everything is important”. As a SCRUM master you will try and convince him to use priorities, and explain that the Project Backlog “is a prioritized list so that the item on the top is the single most important one, with items below that being successively lower priority.”
But how to do it in reality? Let’s get a feeling: for the lack of a real project backlog, try to prioritize a vegtables in a grocery store. It is obvious that Oranges (10 lb) beats Potato (20 lb). But should onion (3 lb) go before tomatos (5 lb) or just after? What about lemons and garlic (1 lb)? Man, it just feels silly. Frustrating. Makes no practical sence. Discriminates the whole prioritizing session. Doesn’t work for me.
This is my approach: In assigning priorities, usually ranged from 1 to 5. Why 5? Just cause I’ve got 5 fingers on my hand, and got so used to it.
On the first round we quickly go through the list and a project owner assigning the priorities from 1 to 5 as he feels. Don’t think too much on computing exact priority to an item: use intuition. When in doubt, give it 3, and move on. Make it fun, and move it fast. We are not going for precision for now.
The result of this quick round is already good enough: look, we got some priorities! So many projects around work with no priorities AT ALL. We are light years ahead of our competitors! Cheer up! Great start!
The second round: refine. Compare equal priorities, escalate more important items, put down tasks that appear less important. Not sure? Appears equal? Fine, keep them. Try it out and you’ll find that adjusting the original rough draft is easy. Few mintues later we are looking at a refined prioritized list that makes sense.
The final touch: count estimated time per priority, write them down on a whiteboard. It will look something like: Prio 1: 3 weeks, Prio 2: 12 weeks, Prio 3: 6 weeks, and so on. This simple math exercise is often incredibly revealing: a collective oh… sh.t are often heard. We brought to our conscious mind how much time we are going to spend on what we named “important”. But how much time we actually have? This conflict usually triggers another burst of thoughts, and some final jiggling of priorities.
At this point our list of items is prioritized just fine to use it for planning the iteration. And it doesn’t take much time to do: we did prioritize lists of 20 items in 10 minutes.
- It is funny that some product owners, in spite of my “5 fingers” reasoning, reported that they can’t work with more then 3 categories. Fine, I let them feel in a driving seat and give them 3 gear transmission: 1st, 2nd and 3rd.
- The advanced technique to tackle less reasonable Product Owner who tends to say “everything is important”. Give them one “1”, a limited number of “2”, and as many “3” as they want.
- If there are about 20 items, 1-5 priorities work efficiently. * If it is more then 25 items, you are in trouble. Consider bucketizing.
- Do the exercise of [re]prioritizing regularly, at least once every iteration, before or (preferably) during the iteration planning.
Cross-posted from Software Frontier