Bug-fixing inside inside sprints or outside?

Today’s post is about how to manage bugs.

First some background. We’re a product developing company and we maintain our own products as they go live. A lot of our work focus on new feature releases for the existing products. We have continuously updated lists of live bugs that has to be dealt with.
Even if you’re not a product developing company like we are, I’m sure that you can relate to the situation.

Ok. Let’s take a minute and look at what a “bug” is, and its difference to “a story”. A bug is something that is often unestimateable. Trying to estimate it may take longer than actually fixing it. Or estimating it may even mean fixing it. A “bug report” is a description of an unwanted behavior of the system or, not seldom, a question about a possible unwanted behavior. Anyway, hopefully it also has some type of “priority” relative to other bug reports (and hopefully there’s a single person who prioritizes – or you’ll have a mess). Of course, bugs are unwanted and we need to strive towards continuously improving so that we avoid bugs altogether. The day we have zero bugs I’ll erase this blog post ;-). But until then we need a way to deal with them.

Since recently we use Trac to manage our bug lists. We used to use Hansoft. We moved to Trac because we felt it was more suited for our needs, and it has an excellent and highly configurable web interface. It is also possible to integrate to Subversion, which is the version control system we use.

Now to the options: Do you bring those bugs into the sprint backlog during sprint planning? Or do you leave room in the sprint backlog to be able handle bugs during the sprint, and maybe even set aside time and resources for it? Or do you have “Bug-fixing Fridays”? Or do you have dedicated teams for it? Or maybe you have “Bug-fixing Sprints”? The options are many, and we of course haven’t tried all. I’ll try here to summarize some of the most obvious methods that I can think of though;


A team of dedicated resources work in parallel to the development teams
This has been the approach in one of our products, for almost a year now. We have two dedicated full-time developers who work with bugs. It works great but it requires these resources to be highly multi-talented. These guys don’t work in sprints (at least not with the bug fixing) and they set aside time for the bug fixing activities; on a few specific days of the week they work with bug fixing and release patches to the live product. The other days these guys work with other “urgent” things which we want to shield from the development teams – much of these things have to do with supporting other internal functions such as sales, advertising, marketing, customer support, etc. We call this team “Client Services Team”.

You’ll need to be careful so that these guys are kept happy. If they want to circulate into development you should try to accommodate for it. Working with bugs can be tiring and stressful. Another downside to this is that the developers who originally cause the bugs seldom get to fix or even see the problems so the bugs doesn’t really serve as an incentive for them to continuously improve. On the upside though the release cycles are short and the bug fixing guys often see immediate result of their work. Also, they get to see and learn to work with a huge variety of technologies and parts of the system.


Dedicate an amount of time during each sprint for bug-fixing
This is our current approach in another one of our products, for a couple of months now. We (most often) do 1-week sprints, so the cycles are short anyway. Not sure this approach would work if we had longer sprints. But we let the development team assume the responsibility for dealing with bugs. They do this by means of two mechanisms;

• Bugs as stories: every week the Scrum Product Owner and the Scrum Masters meet to discuss what’s currently critical or high urgency in Trac, and appropriate issues are taken out and put into the product backlog as stories. They attempt to (guess)estimate them using the StoryPoint value (Gnome Days, see other blog posts below). These stories are merged into the backlog just like any other story, and the prioritization is made relative to any other stories in there.
• Dedicated time every week for “other” bugs: every week (decided on the sprint planning) the team appoints a person and a specific day of the week which will be used for bug fixing (bugs that are not already in the sprint as stories). On that day, Trac is checked for the current buglist and bugs are fixed from top to bottom. Bugs here are not fixed in order of priority but rather in order of size (smallest first). “Smaller bugs” get done faster, regardless of their priority. The idea is to avoid having bugs in Trac open for ages which are really annoyances but that are not critical. I think maybe this sorting on size instead of priority is a sign of the prioritization mechanism not working properly…

This approach seem to work well too, but it requires that the Scrum Product Owner and Scrum Masters really take time continuously to look at the buglist and update the product backlog properly.


Dedicate a whole sprint every now and then
We haven’t tried this approach. I think there are some problems with it. For one, the team will lose pace and we’ll break the Agile principle of “maintaining a constant pace indefinitely” (see http://www.agilemanifesto.org/principles.html). Secondly, the cycle time from bug report to fix will most likely be longer. This approach doesn’t work well for critical bugs that has to be fixed “right away”, unless the sprints are ultra short. Those critical things would most likely end up leaking in to the development sprints. The upside could be that the developers would get to fix their own bugs. It would also force a wider spread of competence throughout the development team(s) instead of e.g. limiting it to certain individuals.


Bug-Fixing Fridays
We haven’t tried this approach either. It sounds interesting enough though. I'm curious to find out if anyone's tried it. It would mean that you regularly dedicate a certain day(s) for everyone to do bug fixing. Maybe every week, maybe more seldom. The problem with this approach though is that it may be hard to have a feeling of continuity in the bug fixing process. And bugs that take longer than a day to fix will end up open for a long time.