Release readiness
Release readiness is the state in which a software build has met every condition the team agreed a release must meet before it ships, with the evidence for each condition current and visible: testing complete and open defects assessed, acceptance signed off, deployment and rollback rehearsed, documentation and support prepared, and no unresolved dependency outside the team. It is what a go/no-go decision inspects, measured against a written checklist.
The longer version
Readiness is assembled from several owners' evidence rather than declared by one person. QA supplies the test report, the coverage of the planned scenarios and the open defects by severity, with each critical one either fixed or explicitly accepted. The business supplies the UAT sign-off. Operations supplies a rehearsed deployment on staging, monitoring in place and a rollback plan with a named executor. Product supplies the release notes and the support briefing. Each item is a line on the readiness checklist with an owner and a status, and readiness is the state where every line is green or its exception is recorded.
Release readiness is the input; the go/no-go decision is the judgement made on it. The two are confused because on a small team they happen in the same meeting, and keeping them apart is what makes a no-go explainable: the decision-maker points at the line that was red. Readiness is also distinct from the definition of done, which applies to a single story and says the work is complete; readiness applies to the whole release and says the assembled work can be shipped. A release of finished stories can still be unready because the rollback was never rehearsed.
Most readiness checklists are assembled on the morning of the release. Items that take days, such as a UAT window or a load test, are discovered late and either skipped or done badly, and the meeting becomes a negotiation about which criteria were required after all. The second failure is a checklist that only QA owns, so that testing is thorough and the support team hears about the release from a customer. The list is started when the release is scoped, each item has an owner where the work is, and a stale item counts as red.
Common questions
What is a release readiness checklist?
A written list of the conditions a release must meet, each with an owner and a status: testing complete and defects assessed, UAT signed off, deployment rehearsed, rollback plan ready, monitoring in place, release notes written, support briefed, external dependencies confirmed. The go/no-go decision reads it line by line, which is why it is fixed before the meeting rather than during it.
Who is responsible for release readiness?
Each line has its own owner, and one person, usually the release manager or the product owner, owns the list as a whole. QA owns the testing lines, the business owns acceptance, operations owns deployment, rollback and monitoring, product owns notes and support. A list that QA alone maintains ends with thorough testing and an unbriefed support desk.
What is the difference between release readiness and the definition of done?
The definition of done applies to one story and says the work on it is complete: coded, reviewed, tested, documented. Release readiness applies to the whole release and says the assembled work can ship: acceptance signed, deployment rehearsed, rollback ready, support briefed. Every story can be done and the release still not ready.
When should release readiness work start?
When the release is scoped, because several items on the list take longer than the final week: a UAT window needs users booked, a rollback rehearsal needs a staging environment that matches production, and a support briefing needs the notes written first. The checklist is created with owners at scoping, updated as each item moves, and read at the go/no-go. A list assembled on the morning of the release only records what was skipped.
What are the most common reasons a release is not ready?
A critical defect that is open and neither fixed nor explicitly accepted, UAT that closed without a recorded sign-off, a rollback that has been written and never rehearsed, a staging environment that has drifted from production so the deployment rehearsal proved little, a partner or dependency that has slipped its date, and a support team that has not seen the notes. Each is a red line on the checklist and each has an owner.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.