By the time most go or no-go meetings happen, the decision has already been made. The date was communicated, the customer was told, the marketing is scheduled. The meeting confirms rather than decides, and everyone in the room knows it.
A readiness check is only real if a no is genuinely available. Everything below assumes it is; if it is not, the honest move is to stop calling it a decision and call it a briefing.
The short answer: before approving a release, review five kinds of evidence. Check that scope matches what was agreed, coverage against acceptance criteria was executed on this build, open defects have explicit accept decisions, UAT was signed off, and the release can be run and rolled back. Then record a go or no-go decision with its owner, its conditions and the risk that was accepted.
Scope: is this the thing we agreed to ship?
- Every requirement in this release has been through elaboration and has acceptance criteria. No item entered development on a one-line description.
- Scope changes since the plan are listed, and each was a decision by the Product Owner rather than something absorbed.
- Anything cut is explicitly recorded as cut, with where it went. Silent removal is how the same gap gets discovered by a customer.
Decided by: Product Owner, on evidence from the Business Analyst.
Coverage: do we have evidence, not just activity?
- Acceptance criteria have mapped test cases. Requirement-level coverage is not sufficient, because a requirement can be covered while half its agreed criteria are unverified.
- Every mapped test has been executed against this build, not a previous one. A pass from three builds ago is not evidence about this one.
- Untested areas are named, not merely counted, and each carries a judgement about whether it matters.
- Negative and boundary paths are covered on anything touching money, identity, or data integrity.
Decided by: QA Engineer.
A high pass rate says nothing about what was never tested. Ninety-eight percent passing across a suite that skips the payment failure path is worse than eighty percent across a suite that covers it. Always read the pass rate next to the coverage gap.
Test exit criteria: is testing done?
Agree these before testing starts, so the end of testing is a check rather than a negotiation.
- Every planned test case for the release scope has run against the release candidate build, or is explicitly descoped with a reason.
- No open critical or high-severity defect remains on a critical path. Such a defect is a stop and cannot be accepted as a deferral; lower-severity or off-path defects can be deferred only with the Product Owner's explicit acceptance.
- The pass-rate threshold for each area was agreed in advance, and is read next to what was never tested.
- Where the evidence lives is recorded: run IDs, reports or links, not a summary from memory.
Decided by: QA Engineer, against criteria agreed with the Product Owner.
Defects: what is broken and what does it cost?
- Open defects listed by severity, with the affected requirement named for each.
- Every deferred defect, which can only be lower severity or off the critical path, has an explicit accept decision by the Product Owner, not an implicit one produced by nobody looking.
- No open critical or high-severity defect sits on a critical path. If one does, that is a stop: it cannot be accepted as a deferral, only fixed and retested, or the critical path taken out of the release.
- Defects found in the last few days are reviewed as a group. A late spike usually means an area is less stable than the totals suggest.
Decided by: Product Owner, on severity assessment from QA.
UAT sign-off: did the business accept it?
- UAT scenarios trace back to the acceptance criteria, rather than being written from scratch on the day.
- Business users ran them on the release candidate, not on an earlier build.
- Every UAT failure is logged as a defect or explicitly accepted as a known issue.
- Sign-off is named and dated, and lists any conditions attached to it.
Decided by: Product Owner, with the business representatives who ran UAT. The Business Analyst prepares the scenarios.
Operational: can we run it, and can we undo it?
- Rollback has been tested, not merely documented. An untested rollback plan is a hope.
- Data migrations have been run against production-shaped data, including the volume.
- Monitoring covers the new paths, so a failure surfaces from telemetry rather than from a customer.
- Support knows what changed and what the likely questions are.
Decided by: Delivery Manager.
The four signals that should stop a release
Most releases that go badly gave warning. These are the four that are worth treating as blocking rather than as concerns to note.
- An untested critical path. Not a low pass rate, an absence of evidence on something that matters. You do not know whether it works.
- A defect trend still climbing. If discovery has not flattened, the remaining count is unknown, and shipping is a bet on a number nobody has.
- Scope that changed without a decision. Something is in the build that was never agreed, which means it was never specified and probably never tested properly.
- An untested rollback. The cost of every other risk on this list multiplies if you cannot get back.
Keep it short enough to be used
A checklist of sixty items gets completed mechanically, which is worse than having none, because it produces documented false confidence. The list above is under thirty checks with a named owner for each group. That is about the limit of what a team will do honestly under time pressure.
If an item on your list has never once been the reason a release was delayed, it is probably not a readiness check. It is a habit.
A go or no-go decision record
Fill this in at the meeting, not after it. If a line cannot be completed, that is the discussion to have.
Release and build:
Decision (go / no-go / go with conditions):
Scope: agreed changes and cuts, decided by:
Coverage: criteria with executed tests on this build; untested areas named:
Test exit criteria met (yes / no, with exceptions):
Defects: open by severity; deferrals and who accepted each:
UAT sign-off: by whom, when, conditions:
Operational: rollback tested, monitoring in place, support briefed:
Stop signals checked (untested critical path, climbing defect trend,
undecided scope change, untested rollback):
Unresolved risks (risk, owner, mitigation, accepted by):
Conditions (what, owner, due):
Decided by, date:
Evidence (links to reports, runs, defect lists):
How ReqLens supports the release decision
ReqLens produces a Release Readiness report for a set of test suites. It leads with execution rate, pass rate, open release-blocking defects and defect density, read from the latest completed run of each suite, and notes any run still in progress that was left out. Its written sections cover risks, blocked work, notable failures, recommended actions, the requirements behind the suites, and what changed since the previous report.
Two things about it are deliberate:
- It states no verdict. The report presents the risk picture and recommends actions, but never says go or no-go. The release decision stays with your team, recorded in something like the decision record above.
- Approving the report is not approving the release. A report is editable while it is a draft; approving it freezes its content so it can be shared and exported as PDF, DOCX, XLSX or PPTX.
All report types, including Release Readiness, are on the Pro and Team plans. For how the underlying links are kept, see the requirements traceability matrix template and how ReqLens manages requirements to release.
Key takeaways
- A readiness check where no is unavailable is a briefing, not a decision.
- Pass rate must always be read next to the coverage gap, or it conceals the real risk.
- Deferring a defect is a Product Owner decision, and an undecided deferral is just an unnoticed one.
- Untested critical path, climbing defect trend, undecided scope change, and untested rollback are stops.
- Record the go or no-go decision with its owner, conditions and accepted risk. A readiness report informs that decision; it does not make it.