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.
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.
Defects: what is broken and what does it cost?
- Open defects listed by severity, with the affected requirement named for each.
- Every deferred defect has an explicit accept decision by the Product Owner, not an implicit one produced by nobody looking.
- No open high-severity defect sits on a critical path. If one does, that is a stop.
- 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.
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.
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.
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 roughly twenty 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.