It’s the start of the sprint or milestone and everyone has come up with plenty of things to work on. The task list is long and as usual, resources are limited. So what we do? Let’s have a meeting to prioritize all the work items!
I’ve attended my fair share of these meetings and they typically take one of two approaches:
Buckets
A very common strategy I see used is to go through the tasks and put them into priority buckets. Typically there are 3-4 buckets called something like P1, P2, P3 and P4. You go into the meeting expecting to come out with a somewhat even distribution like this:
But as the meeting progresses an interesting dynamic develops. The different stakeholders will make an argument for why feature X or Y is very important (P1! must have!). Costs are often not discussed at this point and if they are brought up someone will say “let’s agree on priorities first” (followed by a bunch of head nods).
Agreeing to make something P1 is effortless, while arguing to bump things down to P2-P3 is hard work. And anyone who’s been through this a few times knows anything that is not P1 will likely not get done. So through the path of least resistance you often end up with something that looks like this:
Which is pretty useless in terms of prioritization. Now the sub-teams or individual engineers all run-off to work on their P1s. Which P1s? Most likely the easiest or most fun to work on.
Side note: You also often witness the emergence of the P0 bucket. Apparently calling something P1 doesn’t *quite* convey it’s importance :).
But we can do better …
Ranking
A better alternative is to come up with a sorted (ranked) list of work items in priority order. This is simpler and more effective, but also much harder to do.
Now the prioritization exercise forces the hard discussions and painful decisions. Your feature and mine can’t both be P1, we actually have to discuss which one ranks higher. If something looks to be too far down the list you need to make an argument for what should be bumped down to bring this up.
The list now also informs execution order. So paired with a subsequent costing exercise you can get a good sense of what you’ll be shipping next.
This is not a new idea. Many of the agile methodologies use some sort of priority ranked backlog. But even if you don’t fully utilize any of these methods (I don’t) any team can benefit greatly from having clear priorities discussed upfront.
First image by Mohamed Hassan