Acceptance criteria and release readiness checklist: from a ready story to a go-live decision

This guide is for product owners, engineering leads and buyers of outsourced development who need a release decision that does not rest on confidence alone. Our software quality governance guide explains who owns quality and how the gate fits a vendor relationship; this page gives the working checklists, item by item.

In this guide

• Two checklists, two moments
• Checklist 1: is the story ready to build?
• Criteria patterns by story type
• Checklist 2: is the release ready to go live?
• Size the gate to the risk
• No-go triggers
• Run the go or no-go decision
• AI in acceptance and release work
• Alternatives: how to gate a release
• How Netbase runs acceptance and release readiness
• What delivery record exists, and what does not
• Limits of this guide
• Frequently asked questions
• Next step

Two checklists, two moments

Acceptance criteria are agreed before a story is built. Release readiness is judged after the build, on a candidate that could ship. Mixing them is how teams discover in the final week that nobody wrote down what "done" meant. Keep the first in the backlog and the second in the release record, and make the first feed the second: every acceptance criterion that passed becomes a line of release evidence.

Checklist 1: is the story ready to build?

The Scrum Guide says work that does not meet the Definition of Done cannot be part of an Increment, and that refinement breaks items into smaller, more precise pieces. A story is ready to build when:

• The outcome is observable. A tester who missed the planning meeting can decide pass or fail from what the screen, the data or the log shows.
• Limits are stated. File sizes, volumes, response times you care about, supported browsers and devices, and the roles allowed to do it.
• Failure cases are written. What happens on invalid input, a timeout, a double click, an expired session and a refused payment.
• Test data is named. The roles, records and edge cases needed to test it exist in a test environment.
• Non-functional needs are attached. Accessibility, performance and security needs sit in the criteria or in the shared definition of done.
• Dependencies are known. Other teams, systems or decisions the story waits for are listed, with an owner.
• The size fits one iteration. If the criteria need a page of text, split the story.
• The product owner has approved the wording. Approval happens before the story enters a sprint, not during testing.

Criteria patterns by story type

Write each criterion as a given, when, then sentence, and keep the table above as a prompt, not as a template to fill blindly. The point is that a failing case is described before the code exists.

Checklist 2: is the release ready to go live?

Google's Launch Coordination Checklist, written for its own services, covers architecture, capacity, failure modes, monitoring, security and the rollout plan. The same areas apply to most products, and each needs evidence you can open:

• Scope. Release notes list the stories included and the known issues accepted, each with an owner.
• Functional quality. Acceptance tests and the regression suite pass on the release candidate, verified by someone other than the author.
• Security. Scans ran, findings were reviewed, and every open finding has a named owner who accepted it.
• Performance. Key journeys were measured against the limits agreed in the criteria.
• Data and migrations. Each migration was rehearsed on a copy of real-shaped data, and a backup was taken before the change.
• Rollback. A rollback was tested, or a feature flag can switch the change off without a deploy.
• Operations. Monitoring and alerts cover the new behaviour, the runbook is updated, and support knows what changed.
• Dependencies and configuration. Environment settings, third-party keys and scheduled jobs match between test and production.
• Communication. Customer notices, help pages and internal announcements are ready where users will notice a change.
• Decision record. Who decided, when, on which evidence, and which risks were accepted.

Size the gate to the risk

Not every release needs every line. Three tiers keep the checklist alive instead of ignored:

• Routine change. A small fix passes on automated evidence: tests green, review done, rollback by redeploy.
• Standard release. The full list above, with the evidence attached to the release record.
• High-risk release. Data migration, payments, permissions or a change many customers will see. Add a rehearsal in a production-like environment, a staged rollout and a named person on watch after launch.

No-go triggers

Agree these before the meeting so nobody negotiates them under deadline pressure:

• An acceptance criterion fails or has no test.
• A critical or high security finding is open without a named owner's acceptance.
• No tested rollback exists for a change that cannot be switched off.
• A migration was not rehearsed.
• Monitoring cannot show whether the new behaviour works.
• The person who must sign is not available or was not shown the evidence.

Alternatives: how to gate a release

Choose by four criteria: how often you release, how costly a failure is to customers, how much of the evidence is already automated, and who is contractually accountable for sign-off. Most teams combine the first two or three rows.

How Netbase runs acceptance and release readiness

Netbase runs quality assurance inside delivery: acceptance criteria written with the product owner, automated regression, performance budgets and a release readiness gate, as described on the quality engineering and testing service. Delivery is governed by weekly reviews, KPI dashboards and a dedicated account and project manager, in teams of 3 to 30 that combine analysts, developers, QA and designers. Security practice includes secure code review, vulnerability scanning and penetration testing; Netbase's own credentials cover how Netbase works, not a client's product. Communication is in English, and support runs Monday to Saturday, Sunday off. Most Netbase projects are delivered on fixed-price contracts agreed after discovery, which makes written acceptance criteria the basis of scope; see dedicated team vs fixed price. For a vendor's security answers beside the release evidence, see security questions for a software development partner; the SaaS MVP roadmap shows a launch readiness list for a first release.

What delivery record exists, and what does not

• What exists. The USticker and PrintLeo records describe commerce work with performance and stability improvements, and Netbase's published governance model includes weekly reviews and client dashboards.
• What does not. No Netbase record publishes defect rates, release frequency, rollback counts or the outcome of a release gate, and neither case is offered as proof that a given checklist prevents failures. The checklists here are general practice, not results.

Limits of this guide

• The lists are a starting point; regulated products add their own approvals, such as change records or audit trails, so take specialist advice.
• Metrics such as DORA's change fail rate, the share of deployments that need immediate intervention, show whether the gate works over time; they are outcomes, not items to tick.
• A checklist records evidence; it cannot make a weak test suite strong.

Next step

Share a recent release, its acceptance criteria and who signed it off, and we will book a solution review to adapt both checklists to your team. You can also see quality engineering and testing or more Netbase insights.

Related services and solutions