Wednesday, March 31, 2010

How to allocate time for bug fixes in agile?

Recently I have been discussing with various people about bug fixing and getting high quality software. as part of that I happened to comment a blog entry about incentive driven bug fixing activity called "Bug Week" and thought it to be bad practice due to Deming's points about incentives and the personal experience I have for developing software and managing the development of software. The discussion went even further.. I might address the "objective of zero defects" later as it is a whole different topic addressed by lots of people.

Nate however asked very common question that I have heard from various agile teams:

"How to allocate time for bug fixes in sprints while continuing to add new capabilities to the product."

I have multiple non-incentive driven solutions that I have tried with various teams:

1. The Huitale Way - Drop sprints, Stop-and-Fix

As you might know, we in Huitale practice stop-and-fix as our bug fixing practice.

2. Allocate X% of your velocity for bug fixing and other maintenance tasks

If you need to support an existing version of the product while you are sprinting it is a good idea to allocate time for support/unplanned work/maintenance/bug fixing in all your sprints.

3. Bugs as backlog items

Fixing bug must be valuable. Why not to estimate that business value and prioritize the bugs as items in your product backlog? Some bugs might even not be worth of fixing.

4. Have limit for bugs

Some teams have set a limit for bugs. They try to keep number of known issues less than that limit. When the limit is about to be exceeded by a new bug they will start fixing some bug immediately to make room for the new bug.

5. If you are running Kanban, have a swimlane/SLA/Urgent slot for urgent work

Community members have already described urgent slot, swimlanes, and SLAs so I won't do it here.

In the end of the day it is about everyone taking responsibility and being responsible about the product. If you do not have that, no incentive, set objective or practice will help.


Lasse Ziegler said...

In Scrum teams I've used a combination of 1, 2, 3 and 4.

You allocate some time for the really critical show stopper production bugs. So when you get one you stop-and-fix and then continue with your sprint.

Anything that isn't a show stopper which needs to be addressed immediately goes into the backlog and is handled like everything else in the backlog.

You don't want to have too many bugs in your backlog. It might not be a fixed limit but it sure is something that product owner needs to be aware of and consider when ordering the backlog.

I haven't used a swimlane/SLA/urgent slot mostly due to the projects using electronic task boards that do not support such functionality. I would use a swimlane even in Scrum for the stop-and-fix bugs just so that it very visible that we now have one and that the highest priority is on fixing that bug.

Oh btw, why do you have bugs at Huitale? :)

Marko Taipale said...


Why do we have bugs? :o)

We are mortals after all - under the influence of properties of the system and its common and special causes (like Google changing coordinates in Google Maps, three times already! After first time we luckily added a test to check that and to fail the build).

Fortunately failure is not about being wrong but rather an opportunity to learn and improve :o)

Unknown said...

All of these are good suggestions, but in Point 1 you say "Drop Sprints, stop-and-fix". While I agree with the second part of the phrase I don't understand why "dropping sprints" would be needed.

You can (and maybe should) stop-and-fix despite having Sprints. If you ultimately fail to deliver because of too many "stop-and-fix" situations then you have your very vidible problem that you can analyze (root-cause analysis) and fix.

Sprints are not in any way in conflict with a "stop-the-line" culture.

Another interesting point I'd like to read you thoughts on is "zero defects". I think that we, in the software industry, have nit been disciplined enough about "building quality in"...

Marko Taipale said...


My intention was not to suggest dropping sprints TO apply stop-and-fix. I rather just shared what we have done.

That said I agree with your comment. Retrospectively though I have seen some teams trying to be dogmatic about stop-and-fix and that has resulted them not meeting the sprint goal - scrum master not doing his job obviously but rather following rigid principle.

In our case there is no sprint goal, just promise in a form of SLAs bounded to T-shirt sizing. Measurement of cycle time and "stopping the line" in development will make the bugs very visible.

It would be interesting to hear if anyone has tried (long term) stop-and-fix together with sprints and if there are any conflicts.

Kim Payne said...

Thank you for sharing your ideas. I am looking for better ways to incorrporate bug fixes. We are running continous interations (fixed schedule)and when bugs are discovered by users it is a challenge to integrate them back into the cycle without effecting the schedule. I would like to know more about this topic, so any suggestions would be appreciated.

Marko Taipale said...


If you do not have capacity left ( = you do not anticipate bug fixing as part of your iterations by leaving slack) you simply cannot get it done within the schedule.

PM Hut said...

Hi Marko,

I have published a short article explaining the concept of a bug fixing phase at the end of the project in an agile environment. Maybe you can take a look, here's the link.

Marko Taipale said...

@PM Hut

I wonder what is your definition of done for each iteration.. Is it ok to let the bugs leak to "last iteration" where they will be fixed (... like bug fixing time would be predictable)?

Your approach does not fit us, as we release every day so there is no "hardening" sprint.

I also doubt that it is good idea to let the bugs to stack and trust that you will have time to fix them. If you have time for them in the end of the project why would you not have time for fixing them now?

Erik B said...

my preferred solution: have someone outside the team fix bugs. you can take turns taking this role. this way you don't disturbe the sprint.

if this doesn't work I'd reserve a percentage of the team time to fix urgent (production) bugs and put less urgent bigger issues (and maybe groups of smaller ones) on the backlog. The small ones could also be fixed in some spare time at beginning of end of sprints.