Go or No-Go: The Questions to Ask Before You Release

Introduction

Most release decisions are made in a meeting where someone asks "are we good to go?" and nobody has a reason to say no that they can defend. The tests are "mostly green", the open bugs are "not blockers", and the date has been in a roadmap deck for six weeks.

That meeting is not a decision; it is a formality with a quorum. A go/no-go worth holding has three properties: the evidence exists before the meeting starts, the conditions that would mean no were written down in advance, and one named person decides.

This guide covers what to collect, how to write criteria that can actually fail, and what to measure afterwards so the criteria get better.

Why "are we ready?" is the wrong question

"Are we ready?" invites an opinion, and opinions in a release meeting are shaped by who spoke last and how close the date is. Replace it with questions that have answers:

• Did every check that must pass, pass? Which ones did not, and why?
• What is open, at what severity, and who decided it was acceptable?
• What did the non-functional thresholds actually read?
• If this is wrong in production, how do we find out, and how fast can we undo it?

Each of these has a factual answer that someone can be wrong about. That is what makes them useful.

One named owner, not a vote

Release decisions made by consensus have a predictable failure: everyone in the room assumes someone better informed would have objected. Accountability spread across eight people is accountability nobody has.

The pattern that holds up is a single named release owner who makes the call, with each area contributing evidence rather than a vote:

The product owner is usually not the release owner, and that separation is healthy: the person accountable for the value of the release should not also be the sole judge of whether the evidence is good enough.

The evidence to collect

Gather this before the meeting. A go/no-go where people are opening dashboards is a status meeting.

Test results. Which suites ran, against which build, and what passed. A suite that was skipped is not a pass, and neither is one that was rerun until it went green — if a test needed three attempts, that is a flaky test, and the release owner should be told the number of reruns, not just the final colour.

Open defects by severity. Not a count: a list. "Fourteen open" tells you nothing; "one Major with no workaround in the refund path, thirteen Minor" is a decision.

Non-functional readings. The actual numbers next to the thresholds they were meant to meet — response times, error rates, capacity headroom. A threshold nobody measured is not met.

The rollback plan. How the change is undone, how long that takes, and whether anyone has done it recently. A rollback path that has never been exercised is a hypothesis.

How you would find out. Which alert, dashboard, or metric would tell you this release is going wrong, and who is watching it for the first hours.

Support readiness. Whether the people who take the calls know what changed.

Criteria that can actually say no

A criterion that cannot fail is decoration. Write the thresholds in advance — before the build, ideally before the sprint — because a threshold written while looking at the results is a threshold that will be met.

Weak versus enforceable:

The same discipline that makes an acceptance criterion checkable makes a release criterion checkable, and for the same reason — see how to write acceptance criteria a tester can't misread.

Three answers, not two

Framing the decision as go or no-go makes no enormously expensive, which is how meetings end in go. There are three answers:

1. Go. Every criterion is met, or every exception is accepted with an owner.
2. Go with reduced scope. The release ships without the part that is not ready — the feature stays behind its flag, or the endpoint stays disabled. This is the answer that gets skipped, and it is usually the right one.
3. Hold. A criterion is unmet and cannot be accepted. Name what has to be true to try again.

Keeping option 2 visible is the single cheapest change to most release meetings. It converts "the whole release slips" into "this one feature slips", which is a conversation people will actually have.

Every accepted risk needs an owner and a date

Exceptions are normal. Undocumented exceptions are how the same problem ships four times.

Any criterion waived at the meeting should be recorded with four things: what was waived, why it was acceptable, who owns it by name, and by when it will be resolved. "Accepted by the team" is not an owner. A waiver with no date is not a waiver; it is a permanent change to the standard, made without deciding to make one.

Keep the list somewhere it will be read at the next go/no-go. A risk accepted three releases running is telling you the criterion is wrong, or the work is never going to happen — both worth knowing.

What to measure afterwards

The release decision is a prediction. Measuring it is how the criteria improve.

Escaped defects — bugs found in production rather than before it — are the most direct feedback. The usual form is a rate: defects found in production divided by defects found in total, per release or per period. Vendors publish benchmarks (one puts elite teams under 10% and treats above 25% as a structural problem), but the comparison that matters is against your own previous releases, since what counts as a defect varies by team.

Change fail rate is one of the four DORA metrics and asks a related question from the deployment side: what share of releases required a fix, a rollback, or a patch. Where escaped defects tell you what the process missed, change fail rate tells you how often the release itself went wrong.

Neither number is useful as a target to hit — both are easy to improve by recording fewer defects. They are useful as a trigger: every escaped defect at Major or above deserves a short look at which gate should have caught it, and whether the criterion for that gate was written in a way that could have failed.

A go/no-go checklist

• One named release owner, and they are in the room.
• Every criterion has a threshold that was written before the results were known.
• Test results are per suite, per build, with reruns and skips visible.
• Open defects are listed by severity, with the workaround for each.
• Non-functional readings are next to the thresholds they were meant to meet.
• Rollback has been rehearsed, with a known duration.
• Someone is named to watch a named signal for the first hours after release.
• Support has the release note and the known-issue workarounds.
• Reduced scope was considered explicitly, not just go or hold.
• Every waiver has a named owner, a mitigation, and a date.
• The decision and its evidence are recorded where the next release can read them.

Common mistakes

• Deciding with the date in the room. The date is an input to scope, not to whether the evidence is good enough. Ask what the answer would be if the date were next week.
• Counting green without counting reruns. A suite that passed on the third attempt has told you something, and it is not that the build is good.
• Treating a skipped test as a pass. Skips should be approved in advance and listed, not discovered afterwards in the report.
• "No blockers" as a criterion. Whoever assigns severity then controls the release, and severity assignment is not a decision that should carry that weight implicitly.
• No record. Without one, the next release repeats the argument, and a risk accepted four times in a row looks like a first-time exception every time.

Conclusion

A release decision is only a decision if it could have gone the other way. That requires criteria with thresholds written in advance, evidence gathered before the meeting, three possible answers rather than two, and one person who owns the call and the record of it.

Then measure what the decision missed. Escaped defects and change fail rate will not tell you whether a given release was right, but over a few months they will tell you which gate keeps letting things through — which is the only reliable way the criteria get better.

For the standard that decides whether individual work is shippable in the first place, see acceptance criteria vs Definition of Done.

Sources and further reading

• DORA: the four keys, including change failure rate
• Scrum.org: self-managing defects escaping into production
• DevStats: escaped defects, benchmarks and how to improve
• Addepar engineering: defect leakage and DORA-aligned quality improvement
• Tricentis: software quality metrics that matter