On any software project with a hint of a schedule, there are priorities. There are priorities in choosing features, in assigning attributes to bugs, and in overall project management. Priorities guide the product strategy and the day to day work. We have to decide what to do first, and what to defer. Recently, I have been involved in several "strategic priority setting" sessions, and I have reached a conclusion:

I don't think anyone is any good at prioritization.

Let's start with something “easy” like bugs. Our bug tracking systems at MS are highly configurable, but most teams use Priority 1, 2, and 3 for bug priority. These are loosely defined as:

  1. Fix ASAP. Bug is blocking testing or major functionality
  2. Fix soon. Workarounds are available, but customer scenarios are impacted
  3. Fix if time. Edge cases usually fall in here

These are huge buckets. The line between pri 2 and pri 3, for example is a big blob of blurred gray goo. Worse yet, on some teams, pri 3 is the kiss of death - a priority given to bugs that almost always are postponed to the next milestone, or next release.

"Priority 1" bugs may be a worse problem. If a developer has a pri 1 bug assigned to them, they, of course, should fix it asap. But what happens if a developer has 2 or 3 pri 1 bugs assigned to them? Which one do they fix first?

One answer (and I swear I have seen this happen), is to make the most important bug a priority 0 (zero) bug. That, of course, is not a very good answer, but I've seen it done. Another answer is that the developer just chooses the bug he wants to fix first depending on his mood or who is nagging him the most, or some other random criteria.

So, what's a better alternative (besides banning pri 0)? Three priorities may not be enough, but a bigger part of the problem is that priority assignment is largely subjective. If the individual entering bugs are responsible for assigning priority, the range of subjectivity grows larger based on individual priorities. In other words, I think it's a bad idea for testers to assign priority. Let the triage team assign bug priority. Even with only 3 levels of priority, if one small group of people is assigning priority, there is a better chance that all of the priority 1 bugs really are priority 1 bugs, and all of the priority 2 bugs ...etc.

Now - how many levels of priority make sense? Three is tough, but is 4 enough? How about 10? The answer may depend on the project. If I'm on a team that keeps bug counts low, and I only have 2 bugs assigned to me, it seems a little weird that one is a pri 4 and one is a pri 7 (other than I should fix the pri 4 first…I guess).

What would a priority of 1-n look like? I think bug priority should work more like my netflix queue. Imagine all of the movies in my queue are bugs assigned to me. The movie/bug at the top of the queue is the one I watch/fix first. Better yet (and to strengthen the analogy), the top 2 or 3 movies from my queue are at my house available for me to watch. With a bug queue, I could have a choice between the top 2 or 3 bugs in my queue of which one to fix first. Just as I "tweak" my queue to move things up and down (or immediately to the top), the triage team could adjust my bug queue - either for the individual developer, or for the whole team - to make sure the right bugs were being fixed first.

In addition to fixing the important bugs first, a 1-n solution would likely allow for many more of the pri 3 bugs to be fixed, rather than punted en masse to drive bug counts down (not that this would ever happen …).

Next: Prioritizing features and projects.