To say that it is a somewhat a hot topic among teams around the globe won’t be an overstatement. But should you estimate software bugs?
First, let’s look at the options for estimation that we have in the first place.
Dedicated Time for Bug Fixing
Teams often implement the practice of dedicating a specific time of each sprint / day / week / month to bug fixing instead of estimating bugs using bug management tools, beforehand.
They only estimate if, after the initial investigation, it turns out to be a bigger fix or requires a change to the behavior of the product. It’s more likely that they will treat the bug fix like a feature, that might undergo the complete process of specification, design, development, testing, and release.
Default estimation is another way of estimating bugs, using 0.5 to 1 days as unit values since most bugs don’t take more than a day to get fixed. Some teams have also taken this method to an extreme and treat all tickets like this.
It’s because not only do the things average out over a period of time, but also people get more comfortable with each other and the tickets created become roughly the same size.
Starting with a 0.5 day placeholder for either bugs or features is a good idea. You can adjust it as you become more aware of the issues and how long it takes to resolve them.
Estimation with Historical Data
With enough data, you have the power to create a much more contextual system that would make use of that historical data from your bug management tools to predict the time it will take to fix a certain bug using Natural Language Processing, Machine Learning, and other approaches.
And then there is another school of thought which believes that since you can’t estimate the time it will take to fix a certain bug until you’ve located the problem, trying to come up with an estimate is pointless.
So Should You Estimate Bugs?
There is no definite solution to this problem but we will give you our opinion. There are many factors that should influence your decision on whether to estimate bugs and what approach to use, if so. The most important of these factors are the size of the team and the company.
Also read: A New Approach Use to Document Security
Very logical reasons back both sides of the argument; to estimate or not to estimate.
For: At least one engineer knows the exact source of the bug and how to fix it.
Against: Some bugs are so obscure that it’s hard to predict the time it will take to fix them. In such situations, it’s better to use the default estimation or don’t estimate at all.
There’s no problem in underestimating and overestimating sometimes, but something needs to be adjusted if your estimations are not on point all the time.