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!

2 Comments

  1. Per commented in LinkedIn:

    Interesting! so your outcome of spending 40% of teams time on bugs, is that more bugs are resolved than created – that doesn’t seem that surprising, but maybe I’m reading your post wrong?

    Also, I usually see a 20% of team time dedicated to fixing bugs and other chores, do you see the 40% commitment as temporary, or considered why your teams needs such a high time commitment?

    • My reply:

      There were 2 things that made the situation different from other situations I experienced before:

      1. Way more bugs created have been created than resolved
      2. Several attempts have been tried that did not improve

      The resulting amount of unresolved bugs was so big, that I wasn’t sure if the 40% rule would help or would be just another try that fail.

      I agree – in general its not surprising that more bugs are resolved than created if 40% of the time is spent on bugs.

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.