"Wait a minute. This sounds like rock and/or roll."

Forget Priority and Severity when writing Bugs

Several years ago I was struggling with a very complicated set of rules governing the setting of Priority and Severity in a bug tracking system I was working in.  I did a bunch of reading about best practices but I kept finding answers suggesting complex rules about setting Priority and Severity.  In bug triage meetings I wanted two answer two simple questions: 1) is this bug in the release or not? and 2) in what order should this bug get fixed relative to the others?  I finally found some more compelling articles like this one from Fogbugz which suggested a single Priority field whose purpose was to answer my first question: is this bug in the release or not?

This method has worked fairly well — but more often than not the answer to “is this bug in the release?” is “it depends”.  Rarely did the actual spoken semantics translate to the semantics in our bug tracking system (Blocker, Critical, Major, Minor, Trivial).  We had lots of discussions like this: “This bug is a Major — does that mean it’s in?”, “This bug is just a spelling error, does that make it Trivial?”.  It was still difficult to tell what was in and what was out because we were conflating the size and complexity of the issue with it’s priority; and the semantics weren’t helping.

Here’s what we did: MoSCoW.  I renamed all of the Priorities in our bug tracking system as follows:

Blocker ==> MUST.  This issue must be fixed for the upcoming release or we will not release.  Period.  Fix all of these first.

Critical ==> SHOULD.  This issue _should_ be fixed for the upcoming release.  If push comes to shove we can defer it to the next release. Fix these after the MUST’s

Minor ==> COULD.  This issue is a “nice to have”.  Work on this when all of the MUST’s and SHOULD’s are done or if you need something small when all of the SHOULD’s are too big.

Trivial ==> WON’T.  This one isn’t going to get fixed.  Sorry.  It gets to stay in the system for posterity — maybe some day it will get reanimated.

Major ==> This is the default in our tracking system and was causing problems because it was indicating “not prioritized” but was always stuck on a release.  Therefore Major became UNKNOWN which indicated it needs to be prioritized.  UNKNOWN bugs do not get to be assigned to a release.

Now the rules for setting Priority are simple and the answers to my questions are easy — we get to spend more time fixing and building things and less time talking about Priority.  Incidentally for all of the Lean thinkers out there this change had the side effect of turning us into a Pull system instead of a Push system.

 

Advertisements

2 responses

  1. OK, points taken. But I still have a question. If each bug doesn’t have an intrinsic severity, how can one make an objective judgement about the priority?

    Say, what can prevent people from marking most bugs as “blocker: MUST”? It seems like human nature.

    And how can a bug reporter, coming from QA team but not management team, know which feature is going to be inside next release or not?

    Thanks in advance.

    March 3, 2014 at 10:58 pm

  2. Hi Ray, the simple answer to your question about what prevents people from marking everything as a Blocker is…Nothing! Focusing on rules for this stuff only results in back-channeling. If you have a team of smart motivated people then just trust them to use good judgement. The Potter Test (http://en.wikipedia.org/wiki/Potter_Stewart) is usually the most efficient and effective method (you’ll know a “blocker” when you see it). And of course you can always use the “log-and-flog” method in conjunction with this :).

    March 20, 2014 at 6:57 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s