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 FixItNowOrDeleteIt.com
Get in touch via my homepage if you have questions or comments!
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?
Hi,
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!
“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.”
Totally agree with you ,
This way of handling quality is very bad.
Thank you for commenting. I agree that it would be bad if you delete bugs that you feel you make the quality of your product worse. If I were working on that team I would say that these tiny bugs should be fixed right away. Thatâs the nice thing about this system. Bugs donât get lost in the noise. Since you donât maintain a huge list youâll have a good discussion right away about the bugs as they come in.