In my organization, we do not assign story points to bugs. Some members of my team argue that bugs should slow our Sprint velocity, in order to create an incentive to avoid technical debt and to produce high-quality code. Others, however, argue that some bugs cannot be avoided, and should be reflected in the velocity of a Sprint and in planning meetings. In the collective experience of StackExchange, what is the best practice around assigning story point values to bugs?
2 Answers
Yes, you should estimate points for bug fixing work
There are a variety of reasons for bugs to be found in code, many beyond the control of the developer.
However, there is an exception to the above rule. Do not assign points for bugs found by testers within the Sprint.
In my projects, if the developer worked on a feature and testers found problems, the developer is required to fix them as part of the original estimate. This is to encourage quality coding and avoid slapdash work. We not only do not assign points, we also encouraged the developers and testers to work together and avoid even writing bug tickets for bugs found and fixed within the Sprint. If an intractable bug could not be fixed and had to be carried to the backlog, then we wrote a bug ticket for that. It will be estimated and prioritized as part of the backlog refinement work.
answered Feb 18, 2015 at 21:56
Velocity has one use in Scrum, that is to give the team a means of estimating their capacity for future sprints. It is not a measure of work done, nor should it ever be used as an indicator of the performance of a team.
Imagine a situation where the team is using the velocity as a part of release planning to estimate what can be achieved by a given release date. They would do the calculation based on the stories in the backlog, which represent business value. If the team's calculated velocity includes story points allocated to bug fixing or tasks that do not represent added business value then it is like comparing apples and oranges.
It is noticable that a lot of agile tools recognise this. For example, JIRA Agile only has the story point field on stories and not on other issue types.
As an example, consider a team that decides to allocate story points to bugs they fix in sprints. That team typically manages 20 points worth of stories in a sprint and around 5 points of bug fixing. They record their velocity as 25 story points per sprint. The Product Owner asks for a release planning session as they plan to do a release in a sprints time. They look at the backlog to work out roughly how much work they are likely to complete for the release. Can they assume they will complete around 25 points off the backlog? No they can't, because chances are they will also be fixing bugs as well. So it is likely they will only complete 20 points off the backlog before the release.
It would worry me if some members of the team thought it was necessary to reflect bugs in the velocity. That might indicate that they see the velocity as a measure of the performance of the team rather than purely as a means of estimating future sprint capacity.
answered Feb 18, 2015 at 22:57
-
2Sorry, but this is wrong. Capacity allocated to fixing bugs or doing anything that isn't feature work still represents capacity that could be allocated to something else. Capacity is capacity; how that capacity is spent (e.g. on Product Backlog items, fixing bugs, or anything else) is a business decision managed by the Product Owner. In addition, anyone who doesn't think that fixing bugs or addressing technical debt lacks business value lacks perspective; bug-ridden or broken projects lack customer value, even if the UI is super-shiny.– Todd A. Jacobs ♦Feb 18, 2015 at 23:34
-
I think you may have misunderstood my answer. The velocity is a reflection of the capacity of the team to complete business value stories in sprints. This capacity by definition takes in to account the need to fix bugs, tackle technical debt and any other activity that allows the team to operate successfully. When the team does its forward estimating as a part of release planning it needs the ability to feedback to the Product Owner how much of the backlog will be covered while still achieving the quality levels as agreed by the team and covered in the definition of done. Feb 19, 2015 at 0:07
-
-
2"That might indicate that they see the velocity as a measure of the performance of the team rather than purely as a means of estimating future sprint capacity." This is where you're going wrong. Velocity is not a measure of sprint capacity; it's an estimated range of team capacity to do work--any kind of work. By not adding bugs to the Product Backlog you make bugs invisible work, prevent the PO from prioritizing the all of the work, and treat "capacity" as a measure of product capacity (whatever you think that means) rather than team capacity. YMMV.– Todd A. Jacobs ♦Feb 19, 2015 at 1:06
-
1