A question that often comes up when people start using Scrum for the first time is how to deal with bugs. One approach is to convert them into user stories and add them to the product backlog. This way the bug can be prioritized, estimated and planned like any other requirement, feature or change request.

An important property of user stories is that they are written from a user’s point of view. On a recent project I worked on, the quality assurance people took this quite literally, which gave us a good laugh when presented with the following user story during sprint planning for a student database system:

As [school] principal I want all expected transcripts to be printed every time I press the “Print Transcripts” button. Currently only two transcripts are printed, even though there are more students in the class. The system also stops responding after printing the first two.

I think this is a good example of how a bug can be successfully converted into a user story. After all, when presented like this, we simply had no choice but to make the system do as the principal wanted. I have found “bug stories” like these to be a valuable tool when explaining the concept of user stories to people who are new to story-based requirement specification. When treated like this, there really is no difference between a bug and a feature.

Estimating and Planning Bug Fixes

One of the most common objections people have to converting bugs into user stories and adding them to the sprint is that they see them as very difficult to estimate. To help with this, I often find it useful to split the story up into the following general tasks:

  1. Reproduce error
  2. Find error
  3. Fix error

Estimating will still be hard, but splitting it up makes it easier to assess, theorize and discuss each part of the problem and estimate an effort for each task—it’s a good application of the “divide and conquer” technique. Sometimes the first two or the last two tasks can be merged, i.e. finding the error assumes it’s either reproducible, detectable by reading code or otherwise discoverable by logical reasoning or other problem-solving techniques. Exactly which task split will be the most suitable can vary from time to time, but the concept of consciously dividing the process into smaller parts remains the same.

If the bug report contains a detailed description of how to reproduce the error, the first task can usually be estimated with good accuracy (assuming the described procedure does in fact reproduce the bug in the developer’s working environment). In some cases the steps required to fix the error is known in advance, in which case estimating the first two tasks can be trivial—if they are needed at all—and the third task may be possible to split up and detail even further.

Sometimes the team will have a theory about what portion of the code the error might be in, which can be helpful when estimating the second task. In many cases the developers will also have theories on how complicated the third task will be once the first two are completed (i.e. fixing the error is assumed trivial once the error is found, or the bug is suspected easy to find but hard to fix). Of course, these assumption may not be true, but the tasks and estimates are just guidelines anyway.

If you find it difficult to estimate each task in the bug story, one alternative is to simply decide how much time the team can or wants to spend on fixing this particular bug, and divide the time equally among the tasks. For example, if you decide you want to spend at most 12 hours1 to fix a bug, you could assign 4 hours to each task. Of course, you may still not be able to resolve the issue in 12 hours (or it could take considerably less), but at least now you can plan with it. If the bug is not solved in the assigned sprint, a new story can be created for a future sprint based on the current progress when the sprint ends. If nothing else, the work spent on the first sprint will hopefully make it easier to estimate the required effort for the next sprint.

Alternative Approaches

Converting bugs to user stories is not the only way to deal with bugs when doing Scrum (although I suspect some purists may argue it is). There are also two other popular alternatives that are worth mentioning:

  1. Allocate a certain number of days between sprints to do bug fixing.
  2. Allocate a certain number of hours/days in each sprint to do bug fixing.

Allocating time to work on bugs between sprints is often chosen because it allows good utilization of resources during team “downtime”. Sometimes some team members have other obligations to attend to outside of sprints, and this allows the remaining resources to be active while waiting for the team to get ready for the next iteration.

The second approach can be very effective for teams working on maintaining existing products with potentially large backlogs of bugs and unresolved issues while still developing new features during sprints. It’s also a good way to smoothly transition into an agile development cycle and keep the rest of the organization happy (i.e. support staff) until they are able to catch up with the new way of doing things.

For these approaches it’s not necessarily required to convert the bugs into stories or putting them in the product backlog. When doing bug fixing this way the team can work off a separate bug list—preferably also prioritized by the product owner—and pick new issues from the list as they complete old ones. There is no estimation involved and the work simply stops when the allocated time runs out.

Of course, there is nothing wrong with combining these approaches. For example, any unresolved issues at the end of the allocated time block can be converted into stories and added to a later sprint. Teams have also been known to do entire sprints dedicated to bug fixing, which I have been told has been very successful on many projects.

Notes:

  1. Naturally, this works just as well with story points instead of hours.