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.
/filters:no_upscale()/sponsorship/topic/f1e73882-f385-4f4f-89e2-0799e364e183/CockroachRSB-1684221636780.jpg)
/articles/devex-metrics-framework/en/smallimage/DevEx-a-New-Metrics-Framework-small-1683887713694.jpg)
/articles/dora-metrics-anti-patterns/en/smallimage/logo-1682520876491.jpg){kind=logo}
/articles/api-maturity-model/en/smallimage/LOGO-1681752815249.jpg){kind=logo}
/articles/visual-thinking/en/smallimage/LOGO-1679339789328.jpg){kind=logo}
![[R]Evolutionize Your Retrospectives with Active Sensemaking](https://imgopt.infoq.com/fit-in/50x50/filters:quality(80)/articles/retrospectives-active-sensemaking/en/smallimage/revolutionize-your-retrospectives-with-active-sensemaking-small-1684227204199.jpg)
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/rebuild-tech-culture-layoffs/en/smallimage/how-to-rebuild-tech-culture-for-those-who-survived-the-layoffs-small-1677236107330.jpg)
/articles/secure-delivery-workflow/en/smallimage/logo-1675435091128.jpg){kind=logo}
/articles/energy-consumption-bugs/en/smallimage/logo-1673281703209.jpg){kind=logo}
/articles/motivational-diagnostic/en/smallimage/increasing-team-and-individual-motivation-with-motivational-diagnostic-small-1672932888794.jpg)
/articles/group-coaching-beyond-individual/en/smallimage/group-coaching-extending-growth-opportunity-beyond-individual-coaching-small-1671614956735.jpg)
/articles/platform-engineering-roadmap/en/smallimage/logo-1670836548184.jpg){kind=logo}
/articles/software-testing-energy-management/en/smallimage/logo-1670618011406.jpg){kind=logo}
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
Community comments
Velocity
by Ben Verkroost,
Accounting for Bugs in Agile Development
by Matt Doar,
I remember debating this...
by Jason Little,
Re: I remember debating this...
by Jeff Santini,
Re: I remember debating this...
by Jason Little,
Mike Cohn says assign points to bugfixing-stories (not individual bugs)
by Brad Appleton,
Velocity
by Ben Verkroost,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
(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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Mike Cohn says assign points to bugfixing-stories (not individual bugs)
by Brad Appleton,
Your message is awaiting moderation. Thank you for participating in the discussion.
The paraphrasing of Mike Cohn's blog-post is incorrect. In the post, he does *not* suggest assigning points to bugs/bugfixes. Rather, he suggests creating a user-story for a product-owner-requested "bugfixing activities" where the product-owner agrees to the amount of capacity (effort) of the sprint to be explicitly spent on fixing known bugs that existed before the sprint started.
This does not count toward bugs found during the sprint (at least not or those injected during the sprint). And it is also not the same as estimating the effort (in points) for individual bugs. Rather, it is more of a "bugfix-buffer" where the PO explicitly reserves a limited amount of capacity to be spent on fixing some known problems (which could include technical debt).
The end result of this *does* count those *planned* bugfixing activities toward the overall velocity for the sprint. It does not however count individual bugs as having points toward the velocity.