Release readiness is the evidence-based decision that a release can go to production, usually run as a go or no-go review against the quality gates, the validated scope, and the cutover plan. It is a decision, not a ceremony. The review has a named decision maker, a short list of evidence, and two possible outcomes, one of which has to be genuinely available.
The go or hold release decision, with the evidence behind it, is one of the Deliver practice outputs, and the record it produces is where the Learn practice starts.
How does a release readiness review work?
The review compares three things against what was agreed earlier: the gate results, the scope actually built, and the plan for the hours around cutover.
Gate results come first because they are binary. Each quality gate passed, failed, or was overridden by a named person. That part of the review should take a few minutes if the gates were defined properly, since nothing in it is open to interpretation.
Scope validation is the second part. What shipped against what the MVP boundary said would ship, with the deferrals listed by name. The purpose is not to relitigate scope. It is so that the sponsor approving go-live knows which of the things they expected are not in this release, and so that the deferrals land somewhere rather than evaporating.
The cutover plan is the third. Sequence, timing, who is on call, what the rollback is, when the hypercare window ends, and who owns the system in operations afterward. A release without a named operational owner is a release being handed to nobody.
The decision maker is one person, named before the review, with the authority to say no. The room advises. One person decides and the decision is recorded with its reasons.
What evidence do you bring to a release readiness review?
Bring artifacts, not status. The difference is that an artifact can be wrong in a way somebody can point at. Evidence should be current and about this build: a gate result from three weeks ago on a different build is not evidence about this one. It should cover the whole release, not only the code, which means operations, open dependencies, and the people who will support and use the system, as well as test results. And known problems being accepted into production should be named individually rather than counted.
The rollback deserves particular attention. Work out how long it takes and what it costs while nobody is under pressure. A team that has not answered that question before the review will answer it at 2am, and the answer will be to go forward because going back looks harder.
What does a good release readiness review look like?
A good review is held far enough ahead of cutover that a no-go is actionable. A review on the morning of go-live can only ratify. The evidence has been read before anyone arrives, so the session is spent on exceptions, and the sponsor hears plainly what is not in the release. It ends in a decision (go, no-go, or go with named conditions, each with an owner and a date), and that decision is recorded on the day with the evidence behind it, because the value realization review will read that record later.
What does a release readiness review look like in practice?
Say a state agency schedules the readiness review for its licensing platform three days before a planned Friday cutover. Four of five gates pass. The data migration gate fails: the dry run reconciles on the two largest license types and not on a third that represents a small share of records.
The room's first instinct is to proceed and correct the affected records manually after go-live. The migration owner estimates the manual correction at several weeks of staff time in an office that has not been consulted, and the operations manager, who owns the system after cutover, says that work has no home.
The decision is a conditional go: cutover moves by one week, the third license type is excluded from the initial migration and loaded in a second pass, and the exclusion is communicated to the licensing office before cutover. Two named owners, two dates.
The part worth copying is that the review was scheduled with enough room to change the plan. Held on the Friday morning, the same evidence would produce the same discussion and a different decision, because by then the only remaining option would be to go forward and hope.
Why does a no-go have to be a real option?
Because a review that can only produce a go is a status meeting with a signature at the end. Teams learn quickly which kind they are in. When no-go is not available, evidence starts arriving shaped to support the decision that has already been made: gates get marked pass with caveats, defects get reclassified downward, and the risks that matter get raised in a corridor afterward rather than in the room.
Three things make no-go real. The first is a decision maker with the authority to use it and no personal stake in the date. The second is a date that has slack, or a public statement that the date will move if the gates fail. The third is precedent: a release that has actually been stopped. Until an organization has stopped one, everyone in the room is assuming it cannot happen.
Governance of this kind is an oversight question as much as a delivery one. The GAO Agile Assessment Guide covers decision authority and oversight in agile programs, which is the same ground a readiness review sits on.
What goes wrong with release readiness reviews?
- Held too late. The review becomes a formality because no alternative remains.
- The wrong room. Fifteen attendees and nobody with authority to stop the release.
- Status instead of evidence. Green ratings presented from a slide with no artifact behind them.
- Conditional go with no owner. Conditions attached to the decision become post-launch work that never gets scheduled.
- Nothing about operations. The release is judged on whether it works, not on whether anyone can run it on Monday.
- The record is not kept. Six months later, when the initiative is reviewed for value, nobody can say what was deferred or why.
Release readiness vs a go-live checklist: what is the difference?
A go-live checklist is a list of tasks to complete before and during cutover. Release readiness is a decision made against evidence. The checklist tells you whether the work was done. The review tells you whether the result is good enough to release.
| Go-live checklist | Release readiness review | |
|---|---|---|
| Asks | Were the tasks done | Should this go to production |
| Produces | Ticked items | A recorded decision with its evidence |
| Can it stop a release | Rarely in practice | Yes, that is the point |
| Owned by | The release coordinator | One named decision maker |
| Covers | Cutover mechanics | Gates, scope, cutover, operations |
Keep the checklist. Cutover has real mechanics and they need tracking. Just do not let a completed checklist stand in for the decision, because a checklist can be fully ticked on a release that fails two quality gates.
Where does this fit in PPM4Agile?
Release readiness is the last Deliver decision in the agile portfolio management terms glossary, and it depends on everything before it: gates defined early, scope boundaries that held, dependencies that closed, and a coordination rhythm that surfaced problems while they were still cheap. If your last few reviews have all ended in go and you are not sure whether that is because delivery is healthy or because the review has no teeth, a 60-minute Portfolio Clarity Session is a place to start.