Years ago, I was on a project where the number of bugs was considerably growing day after day. This situation led to a poor backlog management because we had to spend a lot of effort to triage and prioritize hundred of bugs every few weeks, almost all them remained in the backlog for several months. As you have probably experienced, bugs tend to become obsolete as time passes.
As a team, we were aware that most of reported bugs actually were not real bugs but enhancements and they were completely ignored because the priority was to implement new features and of course fix only critical defects. As you know, customers always want value.
It took a time to figure out how to solve the problem. I remember that at the first opportunity, I proposed the Zero Bug Policy based on what I read in articles and books. In my opinion, this was the optimal and effective way to handle the issue but for the team, it sounded a little bit extreme.
The concept of Zero Bug Policy is very simple. There is basically one rule to follow: any identified bug should be either fixed immediately or rejected. In other words, an issue is either a high priority bug or it is not a bug at all.
Here are some benefits of applying this rule:
- Reduce the effort spent in bug tracking
- Eliminate the need of triage and reprioritization of bugs
- Focus on fixing most relevant issues first
- Keep the backlog as small as possible
In our case, finally we adopted a conservative approach that consisted in fixing as soon as possible any critical bug and leave the others to be fixed later in the near future, as long as they are considered relevant.
This rule contributes considerably to the better management of the backlog. However, an effort was still needed to review the existing bugs since their number could not be reduced to zero or close to zero.
I was pretty sure that this could be an important step to apply the Zero Bug Policy in the future.
Top comments (0)