Agile Zone is brought to you in partnership with:

Mike Cohn is a consultant and trainer who specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He is the author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. He can be reached through his website at Mike is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

Should Story Points Be Assigned to A Bug-Fixing Story?

  • submit to reddit

When migrating a product from a traditional approach to an agile one, teams commonly bring along a large database of bugs. These are the result of an inadequate focus on continuously high quality. Shortly into their agile initiative, many teams (and their product owners) decide to aggressively work through the bug backlog. A common approach for doing so is to plan to fix x bugs per sprint or spend y hours on bugs per sprint. Sometimes teams write a user story for this activity such as “As a user, I want at least 15 bugs fixed” or “As a user, I want you to spend about 50 hours this sprint fixing bugs so that the application becomes gradually more high quality.” Even a team that doesn’t explicitly write such a user story will usually include a row on its taskboard to make the bug fixing visible and to track it.

In these situations a common question is whether the team should assign some number of story points to the work of fixing these legacy bugs.

If the team does not assign a story point value to this work, velocity will show the amount of “forward progress” the team is making each sprint. This has the advantage of making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found.

On the other hand, if the team does assign points to the bug-fixing effort, velocity comes to represent the team’s true capacity to accomplish work.

My usual recommendation is to assign points to the bug fixing. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team’s full historical average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints will result in 30 (6*5) more points of new functionality.

Published at DZone with permission of Mike Cohn, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Emma Watson replied on Fri, 2012/03/30 - 3:56am

My take is that that the team and stakeholders need to know both their capacity for new work and their capacity for bug fixing. I recommend that the story points for bugs should not be “lumped in” with the overall story point velocity. The points burned fixing bugs needs to be visible so that the team and stakeholders are fully aware of the cost of low quality.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.