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.