Most development teams around the globe are adopting Agile ways of operating the software development process which is now essential for delivering quality products on time. But dealing with bugs can still be very problematic and needs further simplification, even if you’re equipped with the best issue tracking tools. In this article, we’ll discuss the problem bugs pose and how we can deal with them.

The Problem 

Any good engineering methodology would suggest that before dealing with a problem, you must first identify and define it. In this case, the problem is how to account for bugs within the agile framework of planning, measurement, and estimation. More specifically, how do we measure our velocity and capacity for bug fixing, and how do we measure our performance? And while issue tracking tools can be helpful in this, you still need a method. The nature of bugs is the very reason for complexity. Bugs are, basically, the reflection of our failure to understand how the feature or existing product works. There is always an ambiguity about fixing bugs since we’re mostly unaware of their root cause, and based on that, they can be widely unpredictable and complex. And therefore, estimating bug-fix work and tracking the velocity can be very hard at times.

The Solution

Like most problems related to software development, there is no straightforward solution here as well. But regardless of the school of thought, you belong to, one thing that can be very helpful is to reserve some predetermined capacity for fixing bugs in every sprint. You can maintain separate capacities for bug fixing work vs. feature work if you are estimating your bugs. And if you aren’t estimating your bugs, based on the percentage of the sprint you plan to spend on fixing bugs, simply reduce your overall capacity and only plan that much feature work. For example, if you plan to spend 40% of the sprint fixing bugs and given that you can close 100 points of complexity in a sprint, then you plan to do only 60 points of feature work and spend the rest fixing bugs.

By reserving capacity for fixing bugs, you tune the process to consider the time you want to spend doing other work. You will have a mechanism for tracking the quality and performance of your estimation if you’re grooming bugs. And if you don’t groom bugs, you’ll have sufficient built time into the built schedule for hardening, without any damage to your capacity or velocity. It isn’t a very high-value proposition if you try to estimate bugs and then award your team points for closing them. Without any significant amount of work on part of the developers, the nature of bugs defies estimation, and to be able to plan for fixing those bugs in the next sprint, that work would have to take place inside the current sprint.

But regardless of your preference for working, it can be very helpful to reserve a little capacity for bugs. This will allow you to fix your bugs in a way consistent with Agile practices.