Does a zero-bug policy actually work?

A team of nine engineers had 1,340 open bugs. Nobody read the list. Bugs were filed, sorted, and never seen again. So the new engineering manager announced a zero-bug policy: from Monday, every new bug is either fixed within the sprint or closed as "will not fix". No middle ground, no backlog.

Six months later the same team had 11 open bugs and shipped noticeably fewer regressions. Another team tried the same thing and ended up with 4 open bugs, a furious QA lead, and three production incidents nobody had a ticket for.

The policy was identical. The discipline behind it was not.

Short version

A zero-bug policy means every bug gets fixed or explicitly closed, quickly. The backlog stays near zero.
It works because it removes the option to defer, which is where bugs go to die.
It fails when "closed" becomes a way to make numbers look good.
The whole thing rests on one habit: closing a bug is a real decision, written down, with a name attached.
It suits mature products and small teams best. It suits early-stage rewrites worst.
If you cannot make honest closes, do not adopt it — you will hide bugs instead of fixing them.

What the policy actually says

A zero-bug policy (sometimes called a zero-defect policy) is a rule about your bug backlog, not about your code. It does not claim your software has no bugs. That is impossible.

It says: an open bug is a decision you have not made yet, and you are not allowed to postpone the decision.

When a bug arrives, you have exactly two options.

Fix it now — this sprint, usually within a few days.
Close it — decide it will not be fixed, write down why, and let it go.

There is no "later" bucket. No P4 - backlog. No icebox. That third option is the one the policy removes, because in most teams that bucket is where 95% of bugs end up, permanently.

Where it genuinely hardens quality

It kills the pretend backlog. A list of 1,340 bugs is not a plan. Nobody reads it, nobody grooms it, and a critical bug filed in week three sits next to a typo from two years ago. Removing the list forces the team to look at each bug once, properly.

It makes bugs cheap to fix. A bug fixed three days after it was written is fixed by the person who wrote the code, while they still remember it. The same bug fixed eight months later means an unfamiliar developer reading unfamiliar code, re-testing everything around it. The same fix costs several times more.

It surfaces the real quality signal fast. When bugs must be fixed inside the sprint, a bad release becomes immediately, painfully visible in the sprint plan. Teams stop being able to ship a feature and quietly pay for it later.

It improves what gets built. This is the effect teams do not expect. When developers know they will personally fix every bug in the next two weeks, they push back harder on vague requirements before writing code. Prevention gets cheaper than repair, so prevention happens.

It ends the priority argument. Long backlogs generate endless debate about whether something is P2 or P3. With two outcomes, the conversation is short: is this worth two hours of an engineer's time this week, yes or no.

Where it hides bugs

Now the other side, and it is not a small side.

"Won't fix" becomes the pressure valve. If the metric is "open bugs must be near zero" and the team is behind, closing is free and fixing is expensive. People close. The bugs still exist in the product; they just no longer exist in the tracker. That is strictly worse than a backlog, because now you have lost the record too.

Testers stop reporting. This is the quiet failure and it is hard to detect. A tester who watches five careful bug reports get closed as "not worth it" within a day learns the lesson. The sixth bug does not get written. Your bug count drops, your quality drops, and the numbers say everything is fine.

Small bugs get systematically undervalued. A misaligned button never wins against a feature deadline. Individually, closing each one is defensible. Collectively, 200 such decisions produce a product that feels careless, and no single decision was wrong.

It punishes legitimate slow work. Some bugs are real, serious, and genuinely need a month — a race condition in a payment flow, a deep architectural fault. "Fix this sprint or close it" fits neither. Teams either close something they should not, or bend the rule and quietly restart a backlog under a different name.

It can push work into the wrong place. Bugs get re-labelled as "tech debt", "improvement", or "task" to escape the policy. The backlog reappears with a new name and less scrutiny.

The discipline that decides which one you get

The difference between the two teams in the opening is entirely here.

A zero-bug policy is safe when closing a bug is a real decision with a cost attached. It is dangerous when closing is the easy path.

Four rules make closing honest.

A close needs a written reason. Not a status change. One or two sentences explaining the judgement: who it affects, how often, and why the fix is not worth it now. "Won't fix" alone is not a reason.
The person who closes is not the person under deadline pressure. Usually a triage pair — a tester and a developer or lead together. Sole authority in the hands of whoever owns the sprint is the failure mode.
The reporter is told, and can appeal once. If a tester disagrees with a close, it goes to the next triage session for a second look. Appeals are rare in practice, but the right to appeal is what keeps testers reporting.
Closed bugs stay searchable. Closing is not deleting. When the same issue is reported again by a customer, you need to find the earlier ticket and see the reasoning. Three closes of the same issue is a signal to reopen it for good.

Here is the difference in practice.

Bad close: Status → Won't Fix. No comment.

Good close: Won't fix. Affects the CSV export column order on Safari 16 only, which is under 0.4% of sessions and dropping. Workaround exists (export as XLSX). Revisit if Safari usage rises above 2% or a customer reports it. — Priya, 12 June

The second one takes ninety seconds and is a genuine engineering decision. The first one is deletion with extra steps.

Which teams it suits

Situation	Good fit?	Why
Mature product, steady team, small backlog already	Strong	Bug flow is predictable, so "fix now" is achievable most weeks
Small team (under about 15 engineers)	Strong	Everyone can see every bug; triage is one short meeting
Team drowning in 1,000+ ignored bugs	Good, with a one-time cleanup first	The policy stops the bleeding, but you must clear the old list separately
Regulated or safety-critical software	Careful	Some defects must be tracked to closure with evidence; "won't fix" needs a formal path
Early-stage product, weekly pivots	Poor	Half the bugs are in code you will delete next month; the policy adds ceremony
Large org where QA reports separately to a different manager	Risky	Closing pressure and reporting incentives pull in opposite directions

A softer version that keeps most of the benefit

If a strict policy does not fit, most of the value comes from a weaker rule that is much easier to sustain: a bug bankruptcy line.

Every bug is triaged within 48 hours — fix, close, or accept with a deadline.
"Accept with a deadline" is allowed, but the deadline is real and visible.
Anything accepted and not fixed by its deadline is closed automatically, with a note.
A hard cap on the open backlog — say 40 bugs. If it goes over, no new feature work starts until it is back under.

You keep the forcing function and the honest decisions. You lose the absolutism that makes people cheat.

How to tell whether yours is working

Do not measure open bug count. That number is trivially gamed and it is the whole point of the policy, so it tells you nothing about honesty.

Watch these instead, monthly:

Bugs reported per tester per month. If it drops after you adopt the policy, testers have stopped bothering. This is the single most important number.
Ratio of closed to fixed. If more than about half of your bugs are closed rather than fixed, the valve is open too wide.
Escaped bugs found by customers. The real quality signal. It should fall. If it rises while open bugs fall, you are hiding, not fixing.
Reopened closed bugs. A few is healthy. Many means your closes are wrong.

Frequently asked questions

Does zero-bug mean our software has no bugs? No. It means no undecided bugs in the tracker. Every known bug has been fixed or has a written decision not to fix it.

What do we do with the 1,300 bugs we already have? Handle them as a separate one-time cleanup before the policy starts, not inside it. Bulk-triage by age and severity, close the stale ones with a rescue window, and start the policy on a clean list.

Is it fair to ask developers to fix bugs inside a sprint they already planned? Only if you plan for it. Teams that make this work reserve capacity — commonly 15 to 20% of the sprint — for incoming bugs. Without reserved capacity, the policy just becomes overtime.

What about bugs that need a month of work? Convert them into a scheduled piece of work with an owner and a date, and say so in the close comment. That is not cheating, as long as it is visible and rare.

Can we run this if QA and engineering report to different managers? Yes, but only if triage decisions are made jointly and testers can appeal a close. Otherwise the closing pressure lands on one side and the reporting incentive on the other.