Wednesday, May 19, 2010

Severity or Priority: Stop Making Work For Yourself

One of the primary motivations that lead to the creation of TrackJumper (which is set to launch in a closed beta as soon as next week) was a simple idea that would guide all of our decisions:

If we ask a user to do something, he or she should get a payback in time, money, quality or satisfaction.

It's stupidly simple, yet it's frighteningly easy it is to find examples of bug trackers that create work for their users without generating additional benefit.

Some of this stuff is entrenched in the history of the software industry. Take for example the concept of rating a bug with a priority and a severity. I don't know where the concept came from, but I imagine someone somewhere created a ticket that was very low in priority but very high in severity:
John: Why is this bug rated as very-low priority? It totally crashes the system.
Alex: Because only 1 in 10,000 users will ever see it. 
John: But it CRASHES THE SYSTEM. Are you telling me that's low priority?
Alex: Look, I get that it's serious, but we use priority to help us, well, prioritize what to do next. This one doesn't impact enough people to rise to the top of the list.
John: So, you're telling me that one user that has his entire installation blow up on him would call this a "very low priority". Think of the customers - it's not all about you and your code!
Alex: **groan** Ok, how about this. Lets create another column in the spreadsheet called "Severity". We'll give this one a "very high" severity but a "very low" priority. How's that sound?
John: As long as you get some urgency on this I don't care what you call it. Just don't tell me that something that fails catastrophically is not important.
And the Severity Column is born. It comes from a good place - caring about your customers is good! The trouble is that severity is a totally useless concept. Some might call it a vanity stat. Something that makes you feel like you're getting good, actionable information, but in reality is just sucking time and energy out of your work day.

Does knowing a bug is severe help you decide which one to work on? Yes, but there is more to the story. In the case of John and Alex, Alex correctly understood that even severe bugs that have little impact on the business are low priority. In other words, the severity is baked into the priority. Highlighting it separately does nothing but create confusion, duplicate data, and take extra time to manage.

And that is why TrackJumper tickets don't have a severity field.