The Story of How to Implement a Zero Bug Policy

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

So how do you go about implementing a zero bug policy when you’ve got a long list of real bugs and users and stakeholders who want things fixed? I’ve been getting this question a lot after posting my blog entry Stop Managing Bugs, Start Focusing on Quality and creating the app and cards to help with the day-to-day maintenance of a zero bug policy. So over the summer I wrote a little story board book that will help you get started. Pass by the Crisp office if you’re in Stockholm to pick up a copy, or download the pdf on LeanPub. You can always find more information at


  • 1
    2018-10-24 - 20:08 | Permalink

    Hej hej!

    that’s very tempting concept and I would even become it’s proponent if a following issue would be addressed: tiny bugs shouldn’t be reported if they won’t be fixed immediately.

    There is a category of bugs that are like mosquitos. Tiny but leave unpleasant bites. When there is only 1, then you usually ignore it, since the effort to kill it in the middle of the night (and waking up other family members) is not the best idea. In other words: effort outweighs the pain. But when there are more, then you start considering retaliation and prevention.

    Similarly, there are tiny bugs in your app, here and there, and you feel that reporting each one of them and asking to fix immediately is not quite best approach. You’d rather wait until there is a significant number, which qualifies for “lets fix them all now” OR reduce the cost of answering the question: “is there any quickfix I can do while waiting for something” (like JQL: label=quickfix).

    So, how to approach tiny bugs?

    • 2
      2018-10-24 - 20:30 | Permalink


      Without knowing more about your context it’s a tough question to answer, but I’ll try anyway 😉 Please get back to me if you feel I’ve misunderstood!

      So, here’s how I see it. Most teams don’t discuss what they mean by “tiny bugs”. “tiny” means something different to each person. Is everyone on the team on board with the definition? And do you generally agree that you don’t fix tiny bugs? If that’s the case then the team doesn’t need to log them. However, it’s valuable data if the party logging the bugs is external. Every time that same tiny bug gets relogged by an external party you’ll know that it’s a problem for somebody. This can help you make better decisions about which tiny bugs to fix.

      Basically, this method works best if the whole team communicates and is in agreement about which bugs are “fix it now” bugs and which ones are “delete it”. There’s no reason to create extra paperwork for everybody by logging bugs that everybody thinks should be deleted. However, if there’s disagreement, then the team should absolutely discuss and explicitly decide how to handle a given bug!

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

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