Tuesday, March 1, 2011

Bug wrangling

Many teams have a hard time dealing with how to handle bugs no-matter what methodology they are using.
Teams who are generating a lot of bugs get overwhelmed by them eventually.  This is very stressful and demoralizing.

I've found that initial thoughts are generally around how to manage bugs them rather than why are we getting so many in the first place.  This leads to adoption of things such as bug tracking software, bug cards to be prioritized into future sprints or even a bug squashing sprint amongst others.  Unfortunately when you are in firefighting mode its hard to take a step back and look at fixing the cause rather than the symptoms.

Firstly you need to discover the reason(s) why you are generating so many bugs.

There are few ways to get that information. One way is to, as a team, do a root cause analysis on each bug that comes in.  Use something simple. I like the 5 why's technique.  From here you should be able to find out areas to focus on for a more detailed analysis.

You should also increase your bug transparency. Display your current bugs on cards as an information radiator on a wall, whiteboard etc. Using a tool hides the number of open bugs to a few people, having it on the wall makes it visible to everyone, potentially even customers.

When it comes to bug prioritization my rule of thumb is, make all bugs a priority over anything else.  If it's not high priority enough to do as a top priority, forget about it.

Your product owner should be able to help prioritize.

Traditionally bugs that don't warrant immediate fixing get logged in a bug tracking system and get forgotten about anyway. They get forgotten because they never become high enough priority over stories that generate business value. So why increase your signal to noise ratio.
 
Remember to talk about bugs at stand-up since the team needs to know the ad-hoc work not just project work.

... but I don't have time for this!!

So when will you have time?

If the answer is never then you have a bigger dysfunction(s) in the team. Too many bugs is probably a symptom of a larger problem (and out of the scope of this article). What are your team retrospectives telling you?

If the answer is in a few weeks then consider implementing some of the techniques above slowly. Perhaps only do root cause analysis on major bugs, or get the bugs up onto the wall and talk about them at stand-up.

I'd love to find out other peoples thoughts and perspectives on this issue.

No comments:

Post a Comment