Zero-bug policy questions

clarifications from conversations from this year 2025-09-30 #agile

This year, I’ve talked about implementing a zero-bug policy in a series of conference presentations. I primarily aimed to establish the existence of zero-bug policy success, but I also wanted to start conversations about why more software teams don’t do this.

Conversations include questions. Questions matter: they help you talk to your colleagues about why you can’t adopt a zero-bug policy for your product, and whether that can change.

How did we define bugs vs other kinds of change?

We didn’t. We didn’t need a written definition of a bug, because we evaluated one bug at a time. We only needed to decide whether to fix this bug.

Definitions give you abstractions that you can use to talk about bugs, in general, as opposed to specific bugs. That kind of behaviour leads to meetings and distracting prioritisation games.

Why did we have so many bugs to fix?

Our story started in an early-stage consumer retail startup, a few months after the web shop’s public launch. During this stage, the team addressed online shopping edge cases, and resolving product gaps as they appeared.

Software quality processes hadn’t yet matured, nor had the team worked on software reliability yet. In fact, this situation created the motivation to adopt a zero-bug policy in the first place.

What if we’d started with hundreds of open bugs?

We started with sixteen open bug reports. If we’d had hundreds, like many development teams, we probably couldn’t have faced fixing them all. We’d have had to consider the nuclear option.

As a thought experiment, consider what would happen if you decided to delete your backlog.

Would you get fired?
Would the product face operational problems?
Would the team lose anything valuable?

I hope not. And if not, then why not go ahead and do it?

How do we prioritise for business stakeholders?

As this team’s product manager, I owned prioritisation. Fortunately, the other business stakeholders never wanted to discuss bug prioritisation, preferring to discuss product strategy.

If we had discussed prioritisation, I’d have talked about business outcomes. In practice, we prioritised things like web site traffic, customer satisfaction, and average order value.

Did we refactor, and improve testing, while fixing?

Fixing all bugs took months, because the team fixed quality issues properly. For example, they greatly increased unit test and integration test coverage, and improved code reviews.

Fixed bugs stayed fixed, except for a series of intermittent web shop checkout failures. The team eventually identified the root cause, and redesigned the checkout to prevent failures.

Did we worry about slipping back into many bugs?

The zero-bug policy success phase, with 0–2 open bugs on any given day, sometimes this seemed too good to last. But we gained confidence for each month we didn’t see a resurgence.

As well as better testing, we avoided risky big releases, decoupling deployments from releases with feature flags. New bug reports became less serious, less frequent, and easier to fix.

Didn’t happen. In the first twelve months, we only deleted 9% of bug reports, most of which duplicated other reports.

Rarely deleting bug reports makes deleting related reports unlikely. Even if we did, we’d still address each bug report case-by-case, and decide to fix it sooner rather than later anyway.

📌 As of October 2025, Peter Hilton is available for a new senior product management role (Europe remote, or Rotterdam), and speaking engagements.

Writing by Peter Hilton