Day 27 task: Investigate a 0 bug tolerance.
This task reminded me of a blog post from @punkmik not so long ago Experimenting with a 0 bug policy. I also found another one on my search Zero-Bug Software Development.
I must say, I think one of the companies I worked for did it quite well. We had the feeling that bugs in the backlog brought down team morale most importantly. Yes, bugs mean many other things but poor team morale is something to focus on in order to achieve a good product I feel.
Armed with this experience, when I started my last job one of the first tasks I aimed to achieve was investigate the bug backlog and check what was still relevant, were the priorities still the same, etc. I then paired with the relevant developers to reassess the priority that had been assigned to each bug. One thing we noticed was that lower priority bugs were actually the low hanging fruit. The devs suggested scheduling quick things (the lower priority items) such as typo fixes in with bigger features they were working on.
In a similar manner, with anything of a higher priority we assessed together whether they were bugs, things that needed UX/Project Management input (therefor a feature to be designed rather than a bug) or something that could be closed as soon to be implemented functionality would supersede or fix the issue.
When I finished, did we have 0 bugs? No, but we had more than halved the backlog. I think with full team buy in, a 0 bug policy in that instance was possible but it would have taken a lot of work.
Do you think a 0 bug tolerance is something your team could achieve? If you can will it be a big task to get there? If you already have a 0 bug tolerance, is it working for you and your team? Is it difficult to keep on top of it?