6 reasons not to assign bugs story points

With every scrum team I work with I run into the question: should bugs be given story points? My opinion has always been a clear and resounding ‘no’, and to organise my thoughts and document for future reference I decided to write it down here. Hopefully it can help you, too.

1. Destroys the opportunity to long-term schedule

The average velocity of a scrum team is the easiest way to plan the future based on empirical data¹. So, to communicate a road map with confidence in timings, the PO needs to be able to sum the story points of the road map and then divide by the average velocity. But if in this average velocity 50% of the work actually are bugs, then the estimated delivery dates are 100% off. This is a horrible road map and does not help the customer and will most probably lead to higher team pressure down the road to accommodate for the unrealistic expectations set, reducing quality, increasing the number of bugs and in turn increasing the problem.

2. Gives room to breath

When not giving points to bugs, but still fixing them (as soon as they are noticed, right in the middle of 3 sprints later, even) will reduce velocity. This hurts on the short term, and permanently for those who believe velocity is ever rising. But I argue its a good thing! Using this reduced velocity for your next sprint planning will immediately relieve the team, as forecasted output decreases which should be re-invested in quality assurance in order to prevent new bugs from popping up. Over time, this will prevent any bugs from ever appearing (in theory). And in practice a more truthful and consistent velocity number will emerge, which aids planning again.

3. Bugs are tough to estimate

All estimates are wrong and coming up with estimates is generally very difficult. However, for bugs it is even harder. Explaining a story is fairly easy and most people will immediately paint a picture in their heads about what it entails. This informs their first estimate and the discussions that follow clear up some (hopefully most) differences in views. For bugs, however, it is often times pretty much impossible to assess the impact. Something just “doesn’t work”, but why is usually not known at all. So comparing something this vague thing to a reference story is very tough, and leads to discussions that do not add a lot of value. So better skip them and time-box the effort if you don’t want to be completely derailed by a complicated bug.

4. Learning is reduced

A team ‘scoring’ 0 story points in any sprint should have a passionate retrospective. So, having a sprint full of bug fixes that do not hold any ‘velocity value’ will kick-start the discussion.

More generally, reduced velocity could signal stuff is going wrong and help direct discussions to fundamentally improve, instead of cheering for all the problems from the past that are now finally fixed. The customer gains nothing with a sprint full of bug fixes, no additional business value is delivered, why should anyone be proud?

Don’t get me wrong, fixing bugs is not a bad thing, but if the scene is such that full sprints can or must be committed to fixing bugs, then there is a very big problem in the way the team operates. It helps to have numerical inputs that feel uncomfortable to fuel a discussion to take place. It motivates asking the team how they can do better, or for the team to ask the PO for not letting maintenance slip for so long.

5. You scored the points ‘already’

Although I don’t like to put the story points concept into a game-like context, but if you do, in essence the story points for a bug have once been awarded already. As a bug is, imho, actually a deficiency in a story that has been ‘accepted’ in the past, at which point the story points were ‘awarded’. But that was inappropriate, because the quality was not as expected by the Product Owner.

6. Motivates lying

If the team is being judged based on the number of story points they deliver each sprint (although this is an anti-pattern in itself) giving points to bugs will motivate the team to hide known issues (bugs) to the product owner in the hopes of slipping through. Then, next sprint the bugs appear and can quickly be fixed helping achieve a higher velocity without much effort. Or worse, they would be left in the system, because the team insists that the new bugs be scheduled for the next sprint (and in the meantime annoy everybody that touches the system).

Counterarguments

All work performed during a sprint should be estimated

This is simply untrue. All scrum events are part of the teams work, and although they are being time-boxed, they are not part of the sprint backlog and thus, not estimated. We also do not estimate other stuff that has to be done during the sprint, like visiting the toilet or having lunch. Estimation is not a goal in and of itself, it has to serve a purpose and if it does not, it should not be done.

How can we conduct sprint planning without estimates?

Sprint planning is not about tallying the points and drawing a line. If that were the case, why on earth would 8 hours be assigned to it (for 1 month sprints) and require a full team? This brainless task would be best performed by one individual, a calculator (potentially) and 5 minutes during a phone call about something else (or have your issue tracker perform it automatically).

So, during the sprint planning we need to use our brains some more for giving an forecast and maybe even ignore the points. They are more important for long term planning anyway and re-estimating partly done stories (which is kind of required in this logic) is also a waste of time (more on that in a future post).

If you want the long-term plan and all bugs have points, you can simply correct for the bug-points

Yes, this can be done, but it adds to the effort invested by the scrum team twice. First for properly assigning points, which is very hard (see 3) and then for the PO to do all kinds of rebalancing in Excel. I would say that we have a clear case of Occams Razor, so don’t assign points.

If we fix all bugs immediately without giving them points, we will have a velocity number of 0!

Well, this answers itself I suppose. But to be thorough; if your system is in such a bad shape that this actually is a concern, then a velocity of 0 is probably the reality you are in. It helps no one to lie about this. Face it, fix it and be happier in the end.

The caveats

The arguments above assume a mature scrum approach in which trust is established and where honesty is awarded. This will require quite some work from the scrum master to help stakeholders understand and appreciate the value of low velocity and honesty (where appropriate). If a team gets ‘punished’ for introducing bugs or dropping velocity, they will always start crying louder and louder for counter-productive measures like assigning points, just to re-create a balance of power or feeling of equality. Hopefully the arguments above help teams and scrum masters to improve their narrative and work towards better outcomes for the projects they take on.

Notes

1. See this excellent book by Mike Cohn for more info: Agile estimating and planning ↩