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: Indian Government makes Aarogya Setu open source; Launches bug bounty Programme
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.
Sunday October 25, 2020
Friday October 23, 2020
Friday October 23, 2020
Thursday October 15, 2020
Wednesday October 14, 2020
Wednesday October 7, 2020
Tuesday September 29, 2020
Sunday September 13, 2020
Thursday September 10, 2020
Monday September 7, 2020