Why a genuine 40% bug fix rule worked

A couple of months ago I faced a situation with way more created bugs than resolved ones.

Several attempts to reduce the number of created vs resolved bugs have been tried:

• being vocal about the situation
• introducing metrics created vs. resolved bugs
• making the metrics part of every review

In retrospect the requests to deliver features haven’t been released from the teams. All of the teams’ capacity has been planned and requested and in some situations it was even more.

Capacity

The teams’ capacity has been saturated — sometimes even more has been requested. That caused creating cruft and subsequently more and more bugs.

What happens when you add a new teller was an eye opener for me. With certain time conditions in place, waiting time goes down from nearly five hours on average down to about 3 minutes with a second teller. The waiting time is reduced by a factor of 93x.

I was searching for something that reduces the bugs in a comparable magnitude similar to the example above.

40% rule

The attempt that resolved the ever growing bug problem: a 40% percent rule.

The teams had to spend 40% of their iteration time fixing bugs.

Why 40%

I chose 40% because this translated to two working days. 40% of a 5 days working week is two working days. Such an easy translation was important, because I did not want to define specific working days or hours for the teams. Some engineering teams spend some time per day adding up to 40% per iteration.

Delivery & Specialization

There was an impact on software artifact delivery for sure. The delivery did not drop at the same rate as time has been allocated to bug fixing. I can’t tell for sure why, however the 40% rule applied per team. I trusted team leads and teams to implement the 40% rule well. Some developers could focus on bug fixing, while others were freed up to focus on feature development. Analyzing bugs, identifying root causes, and writing good regression tests requires special skills. So instead of swarming to the top priority task (typically a feature development task), some developers could play out their bug fixing skills from day one of the iteration. In short: specialization.

Outcome

The 40% percent rule significantly improved the resolved / created ratio. Not at an even velocity though. There were times when research tasks revealed more bugs than other tasks. However overall the number of bugs did drop because overall the bug resolution rate was bigger that the bug inflow rate.

What approaches worked for you when you experience quality issues like an ever growing number of bugs?

Matthias Peinhardt — Thanks for your contribution & review!

Originally published at https://www.lotharschulz.info.