Should you estimate your bugs in Agile projects? | David Tzemach

There are many discussions in the Agile community about whether we should estimate our bugs.

In my experience, it all depends on the organization’s culture, the maturity of the teams, the available resources, the quality standards used, and the project goals.

My usual recommendation is to estimate the effort involved in fixing bugs. I generally base my recommendation on the following items:

• It adds value – The common assumption is that bugs should not be estimated, as they do not deliver any value. This is simply wrong. Fixing bugs adds real value to both internal and external quality.

• It increases transparency – When estimating bugs, we can use dedicated metrics that increase transparency into the effort spent handling bugs compared to that invested in delivering “real” business value.

• It helps with future planning – Estimating bugs allows the team to conduct much more efficient planning sessions, as they understand how it will impact their capacity and how much time they have to spend on bug fixing.

Is estimating bugs in Agile really an anti-pattern?

As part of the discussion, there is another voice which states that estimating bugs is an anti-pattern for three main reasons:

R1: Estimating the unknown

It is simply more difficult to estimate bugs because the solution space of a bug is unknown. How can we expect our teams to determine the effort for fixing bugs that are broken in an unknown way.

It is simply unlikely that the team will immediately know the effort involved to fix the bug. If they had the answer, chances are that they would have implemented that solution when writing the code.

In fact, the developers usually have to invest a lot of time in debugging and investigating the code before they figure out what really happened and what needs to be done to fix it.

How can they estimate the amount of work it will take to handle a bug before that investigation takes place? This is why people see the estimation as a complete waste of time since that effort is completely unknown in the first place.

R2: Bugs represent work and not value

Estimating user stories with story points make sense as the number of story points represents the complexity and effort involved in delivering it.

Bugs are different as they don’t add “value” but only work that the team must invest as part of their ongoing development activities. Moreover, estimating them in the first place is simply wrong as the team is rewarded only for the work that adds real “value”.

R3: Misunderstanding the concept of story points

Story points are not a reward and should never be treated as one. The whole concept of using them in the first place is to track the team’s ability to deliver (velocity) and to gain some sense of what we can expect from them in future sprints.

This is where you will usually see the most common arguments in Agile projects, where development teams that can sometimes spend half of their sprints on fixing bugs are not rewarded with story points. This is even if they have succeeded to meet the effort they committed to, which of course leads to great frustration.

You now have enough information to figure out for yourself which is the best approach for your own environment.