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.

This entry was posted in Agile, Alt.Net, Lean, Scrum, TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to The Fly in the Soup of the Iteration

  1. I think I have to agree with the priority of the bugs and whether they are gating or not.

  2. Turkey says:

    thanks You.
    Perfect you Docs.

  3. Robz says:

    I think I have to agree with the priority of the bugs and whether they are gating or not. Some bugs go into the backlog and some get worked on within the iteration for us.

  4. Ben,

    One thing about dedicating a lane to fix bugs, is that you are explicitly allowing for bugs to occur. I would never actually have a plan to include bugs in your iteration, otherwise you get a mindset of “oh if its going to be a bit buggy we’ll fix it next week”. So yes, I would agree that it is a questionable practice. Honestly, I have no other advice than what I wrote in the blog post, which outlines what is currently working for us.

  5. I recently had this discussion with my team. We’d like to be able to just fix all the bugs as soon as they’re discovered, but that does take some planning. Since we do our iteration demo on every other Friday, the bug would have to be discovered by Monday to be estimated and included in the iteration. If we wait that means bugs have a 2 week minimum shelf time, which only increases their cost to fix.

    What we decided is to dedicate a small lane in our iteration to deal with bugs, and try to continually decrease the amount of time we dedicate to such a task. This strikes me as somewhat of a questionable practice, but it allows us to fix bugs in the following iteration, which is key.

    Any tips on what I might do different?

Leave a Reply