You’re close to shipping and you receive a shopping list of bugs and changes. Some are tiny and un-eventful, some are show stoppers, some let the bad guys in, and some are simply scope creep trying to sneak through the door. It’s hard to know where to start without reclassifying them because the majority of them are all labelled Critical. It’s time to sit down with whoever documented your bugs and do some talking…

Listening to The Little Things

I’ve got a secret to share that might make you snicker at me: I used to be a DJ. I played in clubs, and spent large amounts of time and money on music. I still have gear at home to keep the dream alive whenever I feel like playing some Electro.

One of the things you might not have thought about when it comes to DJ’ing is what it’s like to be in a pumping club in the booth.

You have all of the club’s sound system in front of you playing towards the back wall. Loudly.

You have your booth monitor (speaker) turned up louder than the club music so you can hear it “in time” without you mistakenly thinking it’s playing 1 second later because it’s bounced off the back wall.

You also have your head phones on with the next song playing in time, again slightly louder than the booth monitor.

It gets loud.

As the night goes on and your ears get tired, you fight yourself to not turn everything up louder so that you can still hear everything clearly. This is why DJ’s commonly get Tinnitus – everything gets so loud that you struggle to tell the difference between different sounds as you start to go deaf.

Badly prioritised Bugs have the same effect.

Signal/Noise Ratio

Humans are amazing at prioritising if given relevant context information, however when we’re under pressure both project managers, clients and developers alike often fall into the trap of miss-prioritisation with the end result being a wall of “must have” fixes.

When looking back on these situations it’s understandable to see why some of us respond this way. We’re often dealing with a set of not so good circumstances such as:

1. The application needs to go into production a day from now.
2. There are still things you’re working with your testers on that are fundamental. Maybe you don’t even have testers…
3. Maybe the design or BA team decided a week ago that part of the site needs to change in functionality before it ships.
4. But: Everything still needs to be complete in around 24 hours.

In the above situation anyone without any formal guidance, training or experience may easily class “The menu has to be blue before launch” at the same priority as “there is a bug that stop some users from completing the checkout process”.

“…I mean; you understand. This must be completed before we go live…”

To most of us who’ve been here before this seems ridiculous. But in hindsight these situations always look 20/20 – experience simply means you’ve had this 20/20 vision a few times before.

Whatever side of these situations you sit on, classifying bugs and any of the stress or lack of clarity around doing so subsides if your team agrees up front to classifications for bugs.

Get Your Priorities Straight

Every company and software product is different and because of this you should look within your own team and work to not only define the labels for bugs, but how you come to these decisions. Something everyone can agree on.

A common way of doing this is called Cost Of Delay (COD for short), and basically it outlines a framework to asses how important a bug is to the business’s bottom line.

If I use my original example of “The menu has to be blue before launch, a web design agency that has a strong design focus probably has a much higher COD for implementing such a fix than a back-of-office internal developer team. They sell a service of being pixel and colour perfect every time. For context though the same web design agency still probably classify this bug as having a lower COD than “the site doesn’t load at all on a major browser”. It’s not rocket science, but when you think about it using this approach it takes the emotion away. Your designer should understand this just as well as your CEO.

Another good place to look for inspiration on how you classify bugs in your team is by looking towards what others are doing in this space.

If you want to see how some of the big guys do it, take a look at Bugzilla. This system take care of bugs for Firefox, the Linux Kernel, Gnome, Apache and Open Office.

While they classify bugs into similar simple categories, they also work hard to define how they come about these decisions – this kind of straight forward classification should be agreed up front in every team before you start a project.

I Doug, do solemnly swear…

Before my next project kicks off I’m going to set out a standard for how my team plans to classify bugs – and more importantly agree on a definition on what falls into these classifications.

When next entering bugs into your bug tracking system stop and ask yourself “Is it stopping my application working?”, “How does this compare to other blocking bugs” and other reasonable questions before hitting submit. Work to keep your bug list’s Signal/Noise ratio in a state where everyone can still prioritise correctly.

Your other team members will all thank you for it – Probably because they’ll all be able to still hear at the end of the project.