Software acceptance criteria checklist

Start when ambiguity can still change the plan

Draft criteria while refining the product brief and before implementation is committed. Include product, design, engineering, quality and any specialist needed for the risk. Ask what the user is trying to accomplish, what state must exist beforehand and what observation shows success. If the team cannot agree on the expected result, the item is not ready for a reliable estimate or build.

Stop and split criteria that combine several independent outcomes, use vague adjectives or prescribe an implementation without a reason. Words such as intuitive, fast, secure and seamless need observable boundaries. A criterion should be specific enough that two authorised reviewers can reach the same conclusion, while leaving implementation choices to the people responsible for the solution.

Inventory behavior, data and failure dimensions

For each journey, list actor and role, starting state, action, expected interface result, data mutation, messages, side effects and audit or analytics events where relevant. Add empty, loading, invalid, duplicate, unauthorised, expired, offline and dependency-failure states. Include locale, device and assistive-technology conditions required by the intended audience.

Separate business rules from presentation detail and identify the source of truth for each rule. Record external dependencies and what happens when their response is late, partial or rejected. Do not paste sensitive production data into test examples. Use representative fixtures and state who may approve exceptional behavior when a consequential rule cannot be fully automated.

Write examples and assign verification

Use plain statements or structured examples such as Given, When, Then when they improve shared understanding. One example should exercise one meaningful rule. Add negative and boundary cases rather than repeating only the happy path. Link criteria to the story, design state, API contract or policy they clarify so reviewers can resolve conflicts from an explicit owner.

For every criterion, name the verification level and evidence: automated unit or integration check, browser or device journey, accessibility review, security test, performance measurement or manual approval. State environment and required data. Automation is useful for repeatability but not mandatory for every judgment. Manual checks still need steps, expected result and recorded outcome.

Accept the increment with product-wide quality gates

Review story criteria alongside the shared definition of done, which may include review, testing, accessibility, security, deployment, monitoring and documentation across all increments. Record the candidate version and failed or waived criteria. A waiver needs a named owner, rationale, impact, expiry or review point and mitigation. Do not silently convert a failed criterion into a known limitation.

Define acceptance as observable evidence. Examples include a tested user journey, an approved build, reproducible checks, an incident runbook and a verified handover. None of those proves retention, revenue or product-market fit. Keep delivery proof, external provider approval and business results as separate claims.

Preserve criteria through release and handover

Keep executable checks, manual scripts, fixtures, reports and decision records with the owned product systems. Update criteria when a product decision changes and retain enough history to explain intentional behavior. During handover, ask another authorised person to run critical acceptance paths and locate the source rules. This turns criteria into reusable operating knowledge rather than a one-time sign-off document.

Keep source control, domains, stores, analytics, cloud organisations and production credentials under explicit organisational ownership. Grant scoped, revocable access and rehearse handover before the final invoice. The supplier label matters less than whether another authorised person can inspect, deploy, recover and continue the product.

Decision criteria

Use the same questions for every option before choosing.