Alright, stop laughing. This is not an article about some bug-free Nirvana. Software will always have bugs as long as humans are producing it. We’re also not talking about bugs found during the quality control process. This article is about the attitude your software development team has toward the unfortunate—hopefully rare—bug that escapes from the lab, into production, and rears its ugly head in front of your users.


A zero-bug culture is the belief and resulting action adopted by a software team to ensure their production bug backlog remains empty.

The team needs to be fully invested. A top-down dictate will not be successful because the team will ultimately meet the letter of the law and not the spirit of a zero-bug culture. Culture is crucial because it’s a mindset, not a mandate.


So, why would your team want to adopt this mindset? Consider how many production bugs in your backlog is too many. One-hundred? Fifty? Maybe ten is more manageable. Let me suggest that even one bug that is pushed off until later can jeopardize your core mission to implement new features that bring delight to your users.


A codebase free of known bugs provides a stable foundation for your new features. Features built on top of buggy code are likely to be buggy features. Further, fixing the old bugs later will be even harder after features are developed, which depends on the existing, buggy behavior. A team that adopts a zero-bug culture will implement additional practices to capture bugs in their quality assurance process so that they are not hindered in their future feature work.


A zero-bug culture lends itself well to Agile practices. Bugs should be fixed quickly for all the reasons that features should be developed iteratively. Use cases change and features become obsolete. The user who reports a bug today may not care about it later. Users leaving your software because of a bug that is important to them right now won’t be back in 6 months to notice when it’s finally fixed.

Agile velocity or cycle time might suffer initially while the backlog is brought down to zero. However, as the codebase becomes more stable and work from reported bugs recedes to something more consistent, velocity should become more predictable and ultimately increase.


A long bug backlog is expensive in many ways. It’s difficult to mentally process a myriad of bugs and understand what’s most important. Planning, prioritizing, grooming, tracking metrics, and making complex dashboards to display it all can help with comprehending what’s there, but all those things come at a cost. None of that work contributes directly to fixing bugs or developing features. Imagine if you could manage all three of your team’s current bugs at the daily standup!

An example

Here’s a sample process that will help you think about how a zero-bug culture might be achieved. Keep in mind that as part of your team culture, the exact procedures that you follow will be as unique as your team. Tweak this sample or come up with something completely different. Just keep the goal in mind—zero bugs in your backlog!

Fix bugs before features

Fixing bugs before features is key. Since developing new features is what you want to do, forcing yourself to get bugs fixed first ensures that they will get fixed. Later might as well be never.

Calling an issue a bug or a feature becomes more than just semantics. This is why the culture aspect of zero-bug culture is vital. A team that is just conforming to a process may lean too heavily towards categorizing issues as features to keep them out of the bug backlog. A team that has adopted zero-bug culture as part of its identity is more likely to make the categorization decision as fair as possible.

Fix now

Once you’ve categorized an issue as a bug, it needs to go into one of three buckets. The first bucket is fix now. This includes the obvious hair-on-fire scenarios like the Web site being down or there’s an embarrassing spelling error at the top of the home page. It could also include bugs with cumbersome workarounds that are especially exasperating to users. Teams more committed to the zero-bug culture are more likely to place bugs into the fix now bucket.

Fix next

Context switching is expensive, so it’s often prudent to let developers finish what they’re doing. Fix next could mean next sprint for a Scrum team or it could mean next backlog item for a Kanban team. Lower severity bugs that still must be fixed fall into the fix next bucket.

Fix never

That’s right. Some bugs should not be fixed. Reasons include:

• It’s not really a bug.
• It’s a duplicate.
• It’s not worth the effort.
• It’s for an obsolete feature.

It’s okay to just say no. There’s no sense hanging onto bugs that you might fix someday. Like those pants in the back of your closet that haven’t fit since high school, they’re not worth keeping around.

Notice that these buckets, by definition, dictate the maximum age of any bug in your backlog. The fix now bugs are handled immediately and the fix next bugs are handled—at the latest—by the end of the next sprint or cycle time. That means for a two-week sprint, a bug reported at the beginning of one sprint must be worked by the end of the next sprint and can’t be more than four weeks old.

Getting there

Perhaps your team has a long bug backlog and you’re wondering how you can achieve a zero-bug culture. First, dedicate some time to thoroughly vet each item and decide if it fits your new definition of what a bug is. Move or remove items as appropriate. Also, consider simply removing bugs that are older than a certain date. You may be surprised to find how many old or miscategorized items you’ve been accumulating.

Next, decide on a plan to work your bug backlog down to zero. Your stakeholders may not be happy about scrapping all feature work to fix bugs for three sprints. Agree on a path forward. However, once you’ve achieved zero, a zero-bug culture needs to be a part of your team’s process. You wouldn’t think of letting people outside the team dictate how you perform QA, write automated tests, or conduct your standups. Don’t let outsiders dictate whether you can fix bugs. It’s part of who you are and how you deliver software.

One way to promote a quick trip to zero is to track bugs by module within your product. Team members assigned to each module can compete to see their module’s bug count reach zero. Then watch them jump to attack any new bug attributed to their module!

Keeping it clean

There’s a special thrill knowing that you have exactly zero bugs in your backlog. Having a clean backlog will make you feel great and help you keep the promises you’ve made to your users for existing and new features.

Additional reading

Michael Sallmen photo

Michael Sallmen is a software developer who leads a specialized team that facilitates communication between AppRiver’s software development department and other departments in the company regarding issues reported by users. From this perspective, Michael has a keen interest in quickly resolving bugs while still understanding the joy a developer experiences while implementing new features.



Leave a Comment