Count Bug Fixes Towards Velocity? Depends …

by Vikas Hazrati on Sep 16, 2011 |

There have been numerous arguments and debates in the past on whether bug fixes should be counted towards velocity. There does not seem to be a 'one' right answer. However, Agilists have some recommendations describing situations in which they should be added, how they should be added and where they could be avoided.

Syed suggested that whether to count or not depends on how do you categorize velocity. If velocity is based on 'value perspective' then bug fixes should not be counted as they are not adding any incremental value to the customer. However, if velocity is based on 'cost perspective' then bugs should be included in velocity because they take time and effort to fix.

Mike Cohn recommended that bugs should be assigned story points. According to Mike,

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.

Jason Yip made an interesting analogy when he compared velocity as an indicator with which we are running down the field towards goal at the end. Jason emphasized that the important part here is towards the goal.

Now if someone pushes the forward movement back by 5 meters then the velocity is decreased. Hence velocity is more of a vector than a scalar.

Robert suggested a double entry accounting way for determining velocity. According to Robert,

I would count bug fixes towards velocity - but, in the classic tradition of double-entry accounting, I'd also want to take that velocity from the earlier iterations where the bugs were created, and apply it as negative overhead to this one.

Greg commented that putting a blanket statement of not counting bugs towards velocity is dangerous. Whether they should be counted or not depends a lot on the context and the actual definition of the goal

Maybe the goal is new features. Maybe the goal is to produce one feature with many customer exciters. Maybe the goal is to fix bugs in a legacy product. The practice of not counting bugs towards velocity may work for your team, but there are many contexts in which this does not make sense.

Jack Milunsky mentioned that irrespective of whether you end up adding the bug fixes in your velocity, they should be accounted for because they take time to fix.

Bugs should be scheduled into a sprint or iteration along with user stories during the Sprint planning meeting. So the total time to implement tasks and fix bugs should not be more than the available capacity you determined for the Team. I know many coaches will argue that bugs should be tracked separately and that bugs should be dealt with in the sprint that they're found. However in practice this is not always practical. Try it, and you'll improve your teams predictability significantly.

Thus, there is a strong consensus on accounting for bugs. Whether they should be added in the velocity is a question where opinions differ and probably rightfully so, depending on the situation.

Related Editorial

Agile workshops and training

Infographic: Just How Big is the Nerd Economy

Five Key Practices to Agile ALM

Enterprise-class API Patterns for Cloud & Mobile

Agile Maturity Model Applied to Building and Releasing Software

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Velocity by Ben Verkroost Posted

Accounting for Bugs in Agile Development by Matt Doar Posted

I remember debating this... by Jason Little Posted

Re: I remember debating this... by Jeff Santini Posted

Re: I remember debating this... by Jason Little Posted

Velocity by Ben Verkroost

In every proper project testing is part of the process (develop, test, accept, production). Also in Agile projects, testing is a key activity. The best way to measure progress of in my opinion is not to count the bug fixes. A developer can state that a bug is fixed, however a tester proves that his statement is actually true with tests that have passed. The fix of a bug could cause another testcase to fail or in other words create a new bug elsewhere.

In my opinion the amount of passed tests or testcases is the best way to measure progress for a project. It is more accurate because usually the team works towards achieving 100% passed tests or move the troublesome item to a next sprint if 100% is not being achieved before reaching the deadline. Then velocity is measured by comparing the total amount of testcases to be run with the total amount of testcases that passed. The difference between those two counts give the best indication of how much there is to be done.

If Scrum is applied, then this counting could be done per sprint, as the testcases will be prepared per sprint. So for the current sprint this calculation is most accurate. For the whole project an experienced dedicated tester could also estimate the total amount of testcases that are required for the content of the next sprints.

Accounting for Bugs in Agile Development by Matt Doar

(from toolsmiths.blogspot.com/2011/09/accounting-for-...)

I think it helps to view bugs as incomplete features, as in:

"I expected the feature to behave like this, but instead it behaves like that"

So the time spent fixing bugs can be measured in exactly the same way that features can be measured.

I remember debating this... by Jason Little

I remember writing a post about this a few years back. I was wondering if bugs should be estimated. Now I realize there's a better a question(s) to ask. If you ask these questions "do bugs count towards velocity" you are most likely focused on process driven outcomes. When you start asking "why do we have these bugs in the first place", you can start making the shift towards product driven outcomes.

Re: I remember debating this... by Jeff Santini

It seems to me the first point is defining what a bug is. If you are writing your acceptance tests first then a bug must be defined as something that could have been caught with different/better tests. In that case there is a path to eliminate a class of bugs by changing/improving the testing. Of course there are many other scenarios, but this is one.

the next questions is do you make a nice comfy place for bugs to live in your development process by tracking them, and awarding yourself points for fixing them? If so, then it may be that they will stay with you for a long time. If you instead look for ways to change your process to eliminate the way bugs happen then you don't need to track them.

Re: I remember debating this... by Jason Little

True enough, a bug is a matter of perception, it's important the team have a definition of what one is. I find people spend more time debating whether or not "its a bug or works as designed" than trying to figure out what the actual problem is.