A while ago I posted about why I feel you shouldn’t estimate bugs. In a nutshell, if you estimate bugs you’ve essentially ‘double-dipped’ the feature. There’s the estimate for the feature and the estimate(s) for the bug(s) introduced while the feature was being built. If you’re using Scrum defects go to the top, they don’t get estimated and they get worked on until the technical debt is gone. In Scrum, quality is not negotiable so if you’re working on all bugs in any given iteration, the team’s velocity is zero.
There are techniques for using your velocity for being able to forecast your releases but in the real world, and for teams new to Agile/Scrum, you can be working on all bugs or a mix of bugs and features which can make it tough to establish a velocity by having the ability to get into a groove with building stuff that has real business value.
With new Scrum teams or with teams who are not so great at estimating, estimating bugs can be a way to help the team learn to estimate better but those estimates should not be included in their velocity. People, and developers in particular, generally tend to be overly optimistic and if you notice the team is over-committing often, introducing ‘bug estimating’ can be a valuable technique to help the team get better at estimating.
So why does this matter? Why not just estimate bugs and be done with it? The point it, bugs introduced in the sprint get fixed in the same sprint and are not carried over or pushed down the backlog. The other important aspect is that Scrum preaches truthfulness and transparency so by estimating bugs but NOT including them in your velocity you’re not pulling the wool over the businesses eyes by making them think you’re delivering business value when you’re not.