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.
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.
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.
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: Top 10 IoT Mobile App Development Trends to Expect in 2021
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.
Tuesday December 7, 2021
Sunday December 5, 2021
Monday November 22, 2021
Sunday November 21, 2021
Monday November 8, 2021
Wednesday October 20, 2021
Monday October 18, 2021
Sunday October 10, 2021
Sunday October 10, 2021
Thursday September 23, 2021