by Leon Rosenshein

Priority -1

We all have lots of work to do. During the development phase there's often so much work that at any given moment there is more work to be done than there is time to do it. In what we used to call the test phase (now beta or pre-GA) there are defect reports. So how do you know what to work on next and/or when you're done? The traditional answer is priority. When you're doing feature development there are usually 3 or 4 priorities, P0, P1, P2, and sometimes P3. P0 is critical, P1 really important, P2 is nice, and P3 is thanks for mentioning, not gonna happen. Bugs are roughly the same, P0 means fix it immediately, P1 is can't ship/go GA with this problem, P2 people will be sad and we'll fix it in the first patch, and again P3 is thanks for the report, but …

Of course there are variations on this. There's "Unbreak Now" and "Recall class" bugs. Uber Core Business uses Level and Scope to define an outage, with Higher numbers being bigger problems. And as unusual as it is, in many ways that's better.

Because with any leveling scheme there's inflation. When I started at Microsoft tasks and bugs were P1 - P3. And we argued pretty loudly about it. My bug/feature is more important than yours, so I want to be higher priority. There was a lot of passion and energy, so the argument would continue and eventually end up with both at P1. Then the business would shift a little and suddenly there was a new "Most Important Thing". And instead of having the arguments again, the new thing became the most important. And we called it P0 to make sure everyone knew it was the most important thing.

Of course over the next few cycles, instead of everyone arguing for P1, they argued for P0. In general we held the line for a while, but, as with all things inflationary, we eventually lost the battle, and now P0 is the most important thing. Nothing changed except the labels in the tracking system.

I haven't seen a tool that supports P -1 yet, but I'll bet it's out there. We could do it with GitHub if we wanted to :)

But the real problem is that when you have more than 4 items in your list that breaks down. Instead of having actual priorities you just have buckets. And when you have buckets of work you don't have a priority list. You can't determine the order of things getting done because as long as you pull from the right bucket you can do whatever you want and by definition you're doing the right thing. But that's a topic for another day.