Tag Archives: bugs

Estimating bugs in order to get better at estimating

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.

To Estimate Bugs or to Not Estimate Bugs, that is the question

Is it a bug or is it an improvement?  Well, that debate will happen during any project but the purpose of this post is to iterate why bugs (legit bugs) should not be estimated in Scrum.

First of all, if you’re using Agile development techniques, you shouldn’t have any bugs to begin with but in the event bugs are introduced in a project, according to Scrum, they float to the top of the product backlog and take priority over all other work.    Quality is not negotiable.

So to answer the question, no, bugs should not be estimated.  The items on the backlog have been estimated and are the items that deliver business value.  If a bug is introduced and then estimated, the Team has essentially ‘double-dipped’ their estimate for a backlog item since that bug would have been a result of one of the backlog items.  This will throw off your velocity and make it look like progress is being made towards items that deliver business value when that is not the case.  There could be situations where your velocity is zero and that’s fine.   The Team will learn and adjust their development methods to produce zero defects.

The job of the Scrum Master is to make this situation transparent to the Team, product owner and stakeholders so there are no surprises.