Why and how to start a #ZeroBugs policy - part 2

2 minute read

This is the second post of a series about the #ZeroBugs policy. In the previous post, I detailed what a #ZeroBugs policy is and how we tried to apply it. I encourage you start there.

Here is a quick summary of where we stood. We had tried to apply a #ZeroBugs policy with exploratory testing. We had discovered a lot of bugs, and we had agreed to tackle them little by little. We hoped to finish in a few months.

The Bug Panic game

The final bug rules

At about the same time, we started an improvement kata to increase our productivity. I wrote in details about the full story, but to make it short, here is what we discovered :

  • It would take us years, not months to fix all our bugs
  • Our definition for bugs was part of the problem

After some experimentation, here is the bug definition we came up with :

  • It corrupts data
  • It returns wrong results
  • It crashes with an unexpected error message

It stopped scope creep by removing the subjective “it used to work” rule. This rule also sped up bug fixing a lot. We closed many bugs with descriptive error messages.


Within 2 sprints, we reached a #ZeroBugs state. Backlog ‘management’ was simpler as it did not contain bugs anymore. We were also spending less time fixing bugs and more building stories. Even as we resumed our intense exploratory testing sessions, our bug backlog did not grow.

After a while, we discovered other benefits to the #ZeroBugs policy.

Spending less time on bugs made our velocity more stable. Our product owner was happier to see us deliver new features more reliably. In the end, this improved our relationship with him. 

💡 #ZeroBugs policy makes developers happier

It also made the team happier. First, because we had a lot less of stressful emergencies to answer to. Second, because programming new features is more interesting than fixing bugs.

A relaxed developer

It also made the other teams happier and more productive ! They encountered a lot less bugs when using our product. When they had problems, they usually got a clear error message. They would fix it on their side, or suggest us a new feature.

A #ZeroBugs policy and exploratory testing also have a side effect on technical debt ! Bugs tend to appear in the more brittle parts of the code. When fixing bugs, you took the opportunity to refactor technical debt at the same time.

💡 #ZeroBugs policy reduces technical debt

Finally, having a definition for bugs was very helpful. It allowed decentralized prioritization of bugs. The alternative to that is to have a domain expert available to sort bugs from stories. A decentralized rule prevents all sort of coordination and people issues. Our system was rather technical, which made it easy to define what a bug is. In other cases, it might be worth spending some time with the domain expert to define similar rules.

“Use decision rules to decentralize economic control.” From Principles of Product Development Flow by Donald G. Reinertsen

To summarize, sticking to #ZeroBugs is a win-win and sustainable situation for all.

Next week

This was part 2 of a series of posts about the #ZeroBugs policy. In next week’s post, I’ll provide a step by step guide about how to inject a #ZeroBugs policy in your team.

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment