It depends, whether you’re able to make a good application or not, but one thing is for certain – You WILL have to face bugs. The question is how do you estimate them and do you estimate them at all. Some teams don’t bother to estimate and it is justifiable. In this article, we’ll discuss why estimating bugs is not worth the hassle.
Dealing with Uncertainty
The purpose of estimating bugs using defect tracking tools is to gauge how much time and effort should be put in the work. But we can never be 100% accurate with our predictions because there are a lot of variables. Uncertainty can be reduced by improving precision which can be done with user stories, however, bugs are a different case – mainly due to higher risk and complexity. Estimating bugs requires research beforehand which can take a significant amount of time. We usually end up with bad or somewhat accurate estimates, both take a lot of time, which should make one wonder, “is it really necessary?”
A Bug is a Waste
In my opinion, developers should focus on delivering rather than fixing. Customers don’t want bugs. Why shouldn’t we reduce the bugs to a point where the backlog is low in the first place?
Because with fewer issues, the software has more capacity for adding value.
Estimate and Maximize What Adds Value
Estimation can be costly and therefore, everything can’t be estimated. Let’s suppose that there is a backlog filled with items that bring value and items that don’t. We only estimate the first group. After a planning session, some items are estimated using a defect tracking software, some are not. Let’s say, 76 value points and 7 fixed bugs. With 76 as our velocity and nothing more, you may say we should count the bugs too. It would’ve been correct if our aim would’ve been to maximize the value we bring to our customers instead of maximizing the number of bugs fixed. If we spend time on fixing bugs, we prevent ourselves from fixing them, simple as it is. Therefore, estimating bugs isn’t always helpful.
Measure and Visualize
Velocity has an important role in the mentioned setup. It measures how fast we deliver value and how much time is spent on bugs in an iteration. In the example above, we saw that only about 75% of the time was spent on features. For the last couple of iterations, it revolved around 20-30%. This information is useful and as we constantly spend time fixing bugs, maybe we should look at code quality or check if automated tests do their job. Use this metric in case you want to deal with the technical debt. Quantifying the problem is key to prove it and if you successfully convince your boss, fixing it may likely become the next priority. Therefore, measuring and visualizing is very important to find what changes can be made for better.