At some point in time, many Agile teams struggle with how to handle bugs and/or maintenance tasks they are faced with. And the core of this problem is whether bugs should be estimated or not. As always, each approach has its pros and cons, but based on my experience I reckon that estimating bugs is not worth the hassle. Let me explain why.
Bug is a waste
The main goal of every Agile team is to deliver business value to its stakeholders. It’s hard to agree that fixing bugs brings any value, it’s rather a wasted opportunity to deliver features that business waits for. The goal should always be to maximize the value we bring to the customers.
Bugs make long-term planning more difficult
Agile teams usually forecast their long-term plans based on their averaged velocity. In case bugs aren’t estimated (yet regularly worked on) team’s velocity accounts only for features that the team successfully delivers (because only features are estimated). Which in turn enables the team to easily forecast how much value they can deliver in the future (assuming velocity somehow translates into value). In case bugs are estimated forecasting future deliveries becomes much more difficult because the team would need to either know the percentage of velocity that is on average dedicated to a feature development or a number of bugs they can expect in future.
It’s an Agile anti-pattern
In Agile world, a user story is a problem definition and describes a behavior that does not currently exist. When the team implements the solution to such a problem, and it meets acceptance criteria, the story is complete and story points are earned. In other words, the story points represent progress towards the value that the product owner specifies. The defect, on the other hand, represents work (but not value!) that must be done to restore the behavior of the user story.
Now, in case of bugs are estimated, the team would be earning story point for doing work, but necessarily for bringing business value which in my opinion is not what we would like to see.
Moreover, on epic or release level estimating bugs leads discrepancy between team’s burn-up chart (which measures points delivered) and team’s burn-down chart (which measures points remaining). Why? Let’s assume there is a feature to be delivered that is estimated to 80 story points, the team has a velocity of 20 story points per sprint (meaning they need 4 sprints to complete the feature) and they spend whole 3rd sprint on bug-fixing. A burn-up chart would constantly go up (because team burns story point while bug-fixing) while a burn-down chart would remain unchanged (because a number of story point that needs to be burnt to complete the feature is unchanged as the team is busy bug-fixing).
Bugs are hard to estimate
In many cases, bugs are hard to estimate. It’s especially true for old bugs or bugs found in production because the team has already lost the context. Moreover, many teams are faced with having to fix the bugs in the code they haven’t implemented in the first place. Bearing this in mind, how can we expect the team to determine the size of fixing something that is broken in an unknown way? Usually, you either know how to fix the bug (meaning it’s trivial) because you immediately know what is broken or it’s a kind of infinity because you have no idea what is actually broken and how to fix it.
Of course, the team can invest some time investigating and debugging to figure out what is causing the defect. But in many cases, this investigation can take up to 90% of the time needed to actually fix the bug and this investigation effort also can’t be estimated in any sensible way. Usually, it can’t be also time-boxed because it’s not about finding a potential solution to a well-defined problem (like we do in case of new user stories), but it’s about trying to figure out what the problem is in the first place.
What to do
The teams can still plan their future deliveries without having to estimate bugs. The only requirement is to establish a baseline (i.e. each sprint we fix Y bugs and yet still deliver X story points of business value) and use it to outline a plan for next sprints/releases. Of course, actual values (number of bugs and/or velocity per sprint) may (and will) vary, but long-term it should turn to be a pretty effective approach for planning future deliveries. Especially that estimating and planning far into a future brings some level of uncertainty anyways, regardless if you estimate bugs or not.
What’s most important, however, is full transparency which is one of the key factors valued in Agile software development. Stakeholders want to know when the team has delivered value to the customers and they rather don’t care how much work it actually took. Increase in time spent on bug-fixing is pretty quickly visible in a fall in velocity which in turn enables both stakeholders and the team to have an open discussion about it.
