Due to the unpredictable nature of the bugs it rarely makes sense to try to estimate them, unless you know for sure the root cause of a bug. Therefore in most cases estimating a bug is just a smart guess which has a weak relation with reality.
So should a scrum team try to estimate them? Telling the long story short, it depends.
When It Works
In a product company it makes sense to know whether a bug is worth fixing or not, especially on the longer term. The is hidden in a fact that mostly a bug requires proper investigation prior to proper estimation. Quite often though the time required by a bug investigation could also be the same as if there was attempt to fix it without investigation.
On the other hand, this happens rarely, so in other cases we end up creating special investigation stories—”Spikes”. It is a time-boxed interval which a team member should spend investigating a bug and sharing his findings. Once there is enough data gathered regarding a bug—it can be estimated more precisely.
Those spikes should be held one sprint in advance, so for the next estimation meeting the team could discuss the bug with a deeper knowledge.
When It Doesn’t Make Sense to Estimate
When you’re in a service company and have to provide your clients with detailed statements regarding what you plan to do before and what you actually achieved after each iteration.
In other words, when amount of story points literally represent the amount of dollars in the invoice.
Taking into account an average bug unpredictability, attempting to estimate it in advance might lead to hot debates when your team fails to deliver within the promised estimation. Especially considering that from a customer perspective—he won’t understand why should he pay for the bugs that were “initially” introduced by the team and not by the specifications or requirements.
In this case, it would rather make sense to reserve a certain time box during the iteration for bug-fixing and facelifting.
Another Possible Way
When you inherited a large project which has a lot of known bugs and there is no way to fix them all, try to create a separate backlog for bugs and maintain a Kanban flow for them. Make sure you allocate a fixed amount of time per iteration for handling these issues, sort of a hackathon days.
Depending on the size of your bug backlog, the time box size may vary. But having 20% of the time reserved for bug fixing is a common practice.
Product bugs require constant grooming. Don’t try to estimate them precisely, but rather evaluate them in terms of certainty. If a team is certain that this is an easy fix—take it. Otherwise—be careful.
The biggest mistake during the estimation meeting while discussing a bug is to start investigating it during the meeting. Once everyone is on fire, it is quite easy to lose the focus.
Keep your estimation on track.
Thanks to Jeremy Jarell for sharing his experience,
which was the base material for this post