BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Count Bug Fixes Towards Velocity? Depends …

Count Bug Fixes Towards Velocity? Depends …

Leia em Português

This item in japanese

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.

Rate this Article

Adoption
Style

BT