This is a follow up to my original post about implementing a zero-bug-policy. With my team at Rabobank, we've embraced this policy and I want to share our experience from the last year.
A year has passed
We started out with a backlog littered with about 140 bugs. We were aware that a part of those could be closed instantly, for a couple of reasons. Basically it came down to try to reproduce the bug, and if it was not possible, we would log the reason and close it. Some example reasons to close issues were:
- bug already fixed (side effect of a refactor, for example)
- a duplicated ticket (people don't look for duplicates when reporting, I don't blame them)
- the bug context no longer exists (feature removed or changed so the behaviour is gone)
Initial scan
It took some serious effort to go through all these tickets, some of which had been opened years before. But it was really satisfying to be able to close about 40 or so tickets, just because the administration was messy. This left us with something over 100 bugs that were valid.
From many to not so many
About 100 open bugs can still be daunting: how do you ever get to zero? Our goal for each sprint was to at least have less bugs on the backlog than at the start of the sprint. At the end of each sprint, we would log the closed bugs, opened bugs, and the grand total open. During demo's we were transparent about the process so everyone could see how we were doing. It also helps you as a team to have an extra reason to do well on this part: a lot of stakeholders really liked our progress so we really wanted to keep that up!
Example of one of our bug status reports during sprint review
| Critical | Major | Minor | Trivial | Total | |
|---|---|---|---|---|---|
| Open at start | 0 | 1 | 2 | 2 | 5 |
| New reports | 0 | 0 | 1 | 0 | 1 |
| Closed | 0 | 1 | 1 | 1 | 3 |
| Open at end | 0 | 0 | 2 | 1 | 3 |
In periods where we had less demand for new features or changes, there was room for specific focus on bug fixing and we were able to get it down with big jumps: this really boosts team morale!
Having zero bugs
Somewhere at the end of last year we finally made it to the zero! It felt as a big achievement, and it had some very positive side effects as well:
- less pressure from stakeholders that try to get attention to open issues: we didn't have any!
- We jump immediately on new bugs, and because of this we are pretty fast to solve them: if you take on bugs that are still hot from the plate, you can get context and background information very easily, and the reporters are very much willing to help out.
- A clear, up-to-date backlog!
Note: Having zero bugs on the backlog does not mean they don't exist: this policy is just meant to take bugs heads on when they are reported.
As a team we really take pride in having no open bugs, and it gives us also peace of mind when shipping new code and working on new features. It also saves much time during planning sessions (bugs always must be picked up) and if a bug is much more trouble or reveals a bigger issue inside, you are very quickly made aware of it.
I'll try to advocate for this policy as much as possible, as my personal experience, as well as that of our team (including our product owner) has been very positive!
Top comments (0)