Count Bug Fixes Towards Velocity? Depends …
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.
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
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...
Re: I remember debating this...
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.