07.16.09
Ranking vs. Prioritizing
Just finished writing up a list of some ’stuff’ for work (what it was is totally unimportant). Part of this list included prioritization of the items, and for a first pass I went for three priorities, P1, P2, P3.
After writing the list, I noticed that, as typical for prioritization systems, I ended up with a bunch of stuff in P1, some stuff in P2, and almost nothing in P3. Since I’ve seen this anti-pattern before, I decided that I would split them up into groups of equal size.
Boy, was that hard. Even without complete stack-ranking, coming up with equally-sized groups forced me to think about which of the items were important, and why, in a way that just arbitrarily assigning priorities did not.
After doing this, I’ve become even more convinced that prioritizing is a waste of time, and that stack ranking in some form is, really, what is needed. Prioritization alone does not force you to really think about your requirements and what is really important, and seems to inevitably end up with a “top priority is everything we think we’ll do, second priority is everything we’ll do if we have time, and third priority won’t get done” schema.
I don’t know if total stack ranking of every possible feature or work item is necessary, but I think that, at the minimum, you need to have small groups of equal size (probably no more than 5-10 items), and those need to be ranked. This gives some flexibility in terms of not overly worrying about whether items 1 and 2 should swap (since they’re both likely to get done), but still acts as a forcing function in that you’re limited to ‘n’ top-priority items.