The Fly in the Soup of the Iteration

Where do bugs fit into your iterations?  This is a discussion I’ve had on many occasions with many different people.  Laribee mentioned they work bugs as soon as they come in.  I believe Bellware told me the same thing.  Provost and Newkirk both told me they get bugs prioritized into the backlog along with everything else as they come in, and they get estimated and put into a specific iteration along with the stories.

I’ve tried it both ways.  On the same project even.  We have gone from working them into the iteration, to doing them when they come in, back to working them into the iteration.  We weren’t as successful as we would have liked either way.  Bugs are always hard to deal with, because you don’t exactly know what’s wrong and everything is just guesswork until you go in and look.  And by the time you go in and look to see what could be the problem to estimate how long its going to take to fix it, you find out the majority of your bugs take a change to a single line of code (of course, write your unit test first to simulate the bug and fix the code).  90% of your time is spent figuring out what is causing it.  This is where the estimation of bugs has to hit, on the figuring out, not necessarily the fixing.

So how to handle this?  Well, you have to mix together a few different strategies in reality.  Some bugs will come across in the bug tracker as high priority, things that are hurting the production system and must be resolved within the next few days.  Many others will not be as high priority.  What my team does now, and it has worked very well, is when a critical bug comes in, the next person to finish a task will pick up the bug and work it.  All other bugs go into the backlog.  At any given time we have between 10–15 bugs in our backlog.  These are bugs that get worked on Friday mornings and afternoons as the iteration winds down and stories become completed and resources become available.  This has had very little impact (no noticable impact, actually) on our velocity and backlog curve.  So in the end we are not really estimating bugs.  For metrics purposes, we only keep track of a bug count, not an estimated velocity of what it would take to resolve a stream of bugs.

Short iterations, another topic I’ve been meaning to talk about, certainly helps deal with quick turnaround on high priority bugs.  If you are working 4 week iterations, the turnaround on a bug is horrendous unless you branch, resolve, merge… puke.  Either way, its still several days to get the bug out at worst case, which is no different than just working 1 week iterations.

Source Click Here.