QUICK ANSWER
What should an acceptance criteria template include?
An acceptance criteria template should include a stable criterion ID, parent requirement or story reference, review version, one observable rule, known context, one event, expected outcomes, boundary category, evidence requirement, accountable reviewer role, and draft or review-ready status. It should not record test execution, UAT signoff, or release approval.
Acceptance criteria turn one reviewed requirement or story into observable conditions that a product owner, builder, tester, and business reviewer can understand before implementation begins. Useful criteria state known context, one meaningful event, visible outcomes, important failure boundaries, and the evidence a later reviewer should inspect.
This downloadable pack includes a blank Markdown template, ten fictional criteria in JSON, a closed JSON Schema, matching CSV and Gherkin review views, a dependency-free validator, 47 tests, and a deterministic ZIP builder. It keeps acceptance criteria separate from the full user story, backlog order, executable test cases, QA strategy, UAT signoff, and release authorization.
Write acceptance criteria from product boundary to review evidence
Start from one reviewed parent item and make its important behavior observable. Keep the criteria small enough to discuss while making failure, authorization, retry, and recovery behavior explicit where the risk calls for it.
Link the criterion to one stable parent item
Reference the reviewed requirement or user story and its version instead of rewriting the product problem, actor, value, scope, or backlog position. A criterion clarifies the parent behavior; it does not replace the parent decision or approve it.
Sources: [acceptance-pack], [govuk-user-needs], [cucumber-user-story]
State one observable rule without implementation detail
Write what a person or external system can observe, not which component, database table, function, or test framework should create it. Plain outcome rules work for compact boundaries; short scenarios help when context and sequence matter.
Sources: [govuk-better-acceptance], [cucumber-gherkin], [acceptance-pack]
Use Given, When, and Then only when it adds precision
Use Given for known context, When for one meaningful event, and Then for observable outcomes. Keep examples short and domain-focused. A Gherkin-shaped statement becomes executable only after maintained step definitions, fixtures, and a real run exist elsewhere.
Sources: [cucumber-gherkin], [cucumber-user-story], [acceptance-pack]
Cover the risks that can change acceptance
Add criteria for relevant invalid input, authorization, duplicate or retry behavior, concurrent updates, provider partial failure, recovery, and accessibility. Do not copy every category into every story; choose the boundaries that could change the product decision or user outcome.
Sources: [govuk-better-acceptance], [acceptance-pack]
Name evidence and preserve separate decision records
Describe what a later reviewer should inspect and who owns that review. Test cases own fixtures, steps, runs, actual results, verdicts, and defects. UAT owns representative business execution and signoff. The Definition of Done owns shared Increment quality, not story-specific behavior.
Sources: [scrum-dod-boundary], [acceptance-pack], [json-schema-2020-12]
What this acceptance criteria template owns
Use the pack after a requirement or story has a stable identity and bounded outcome. It creates a criterion-level review record without inheriting product, test, acceptance, or release authority.
Included
- Stable criterion ID, parent item reference and version, order within that parent, format, category, and review status
- One behavior rule with known context, one event, observable outcomes, and an explicit evidence requirement
- Outcome-rule and Given/When/Then formats without requiring one notation for every criterion
- Worked fictional coverage for happy path, invalid input, authorization, duplicate retry, concurrency, partial failure, recovery, and accessibility
- Accountable product, business, QA, security, accessibility, and operations review roles
- Closed JSON shape, matching CSV and Gherkin views, mutation tests, credential checks, and deterministic archive production
Not included
- Full user-story actor, need, value, decomposition, dependencies, risks, ready/done boundaries, or backlog ownership
- Product backlog ordering, refinement state, estimate, Sprint selection, commitment, task plan, or delivery schedule
- Test-case fixtures, preconditions, executable steps, expected-step results, runs, actual results, verdicts, defects, cleanup, or automation status
- Test-plan environments, data strategy, suites, entry and exit gates, execution evidence, recovery strategy, or production smoke orchestration
- UAT participants, representative business scenarios, execution results, known-risk decision, signoff, release authorization, or production approval
- Guaranteed implementation quality, accessibility, security, compliance, delivery, adoption, traffic, leads, sales, revenue, approval, or product outcome
DOWNLOADABLE RESOURCE
Download the acceptance criteria template pack
Use Markdown for collaborative drafting, JSON as the controlled source, CSV for review, and the Gherkin view for scenario discussion. The fictional Harbor Lantern workflow keeps criteria traceable while preserving the boundary to later tests and decisions.
Acceptance criteria template pack
A criterion-level record pack with stable parent references, observable rules, boundary categories, evidence requirements, reviewer roles, and explicit authority limits.
Format: Markdown, JSON, JSON Schema, CSV, Gherkin, and dependency-free Node.js validator/tests in one ZIP
Locally reproduced August 1, 2026. SHA-256: f6a551d06ea5abfd8e223840bed5d9172c8edada159d2e091720cb6f965dcc8e
Included
- Blank Markdown acceptance criteria record and adaptation guidance
- Completed fictional JSON register with three parent references and ten criteria
- Closed Draft 2020-12 JSON Schema plus matching CSV and Gherkin review views
- Dependency-free validator with reference, order, category, boundary, contact-data, and credential checks
- Forty-seven deterministic tests and a fixed-timestamp ZIP builder with an exact ten-file allowlist
Verification boundary
The exact archive allowlist, extracted-byte parity, repeatable SHA-256, closed record shapes, stable references, consecutive per-parent order, required risk categories, observable result arrays, reviewer references, CSV and Gherkin parity, false authority flags, reserved fictional values, malformed inputs, and credential patterns were checked locally. Public availability and adapted criteria quality remain separate gates.
Four acceptance criteria patterns with different boundaries
Choose the smallest format that makes the behavior unambiguous. Each pattern below states the product boundary and the review evidence without becoming a test execution record.
Observable outcome rule
Use when: One compact condition can state the user-visible result without important context or sequence being lost.
Link the rule to a parent item, name one observable result, and avoid interface or storage implementation. Add separate criteria when invalid or authorization behavior would change acceptance.
Structure
- Parent item and version identify the product decision being clarified
- One outcome rule states what must be observable and where evidence should appear
Watch for: A checklist phrase such as “works correctly” is not observable and cannot guide a later review.
Sources: [govuk-better-acceptance], [acceptance-pack]
Given, When, and Then scenario
Use when: Initial context, one event, and one or more observable outcomes need to be read together.
Keep Given to known state, When to one event, and Then to results visible to a person or external system. Use several short examples instead of one scenario with many branches.
Structure
- Given identifies context and preconditions without acting through the interface
- When names one event; Then names outcomes rather than internal database state
Watch for: Gherkin syntax is specification text until step definitions and a test run prove executable behavior.
Sources: [cucumber-gherkin], [cucumber-user-story], [acceptance-pack]
Authorization and stale-conflict criteria
Use when: Private records or collaborative updates can expose another account or silently overwrite a newer decision.
Use ordinary accounts in separate scopes, derive authorization from the signed-in context, and make allowed, denied, and stale-version outcomes independently observable.
Structure
- Authorized criterion proves one allowed transition and version increment
- Denied and stale criteria prove non-disclosure and no silent overwrite
Watch for: A hidden button, guessed URL, timestamp, or client-provided workspace ID is not an authorization or concurrency policy.
Sources: [acceptance-pack], [json-schema-2020-12]
Provider partial-failure and recovery criteria
Use when: A durable product result can succeed before an optional email, payment, storage, search, or other provider attempt finishes.
Separate the product record, provider operation identity, attempt events, retry boundary, late result, and reconciliation. Make degraded behavior observable without claiming provider delivery.
Structure
- Partial-failure criterion preserves the durable product result and records a bounded failed attempt
- Retry and recovery criteria preserve identity and append history without rewriting the original result
Watch for: Fictional local criteria do not prove provider credentials, transport, approval, payment, delivery, or target-environment behavior.
Sources: [acceptance-pack], [scrum-dod-boundary]
Decide whether a criterion is review-ready
A criterion is ready for accountable review when its parent, behavior, evidence, and boundary are clear. Use these stop rules before implementation turns ambiguity into accidental product policy.
The criterion has no stable parent reference or would change product scope
Choose: Return to the requirement or user-story owner, update the product decision, and link the criterion to the reviewed version.
Tradeoff: Implementation pauses, but the criterion no longer acts as an unauthorized substitute for product scope.
The rule says only that something works, is easy, or is successful
Choose: Rewrite it around known context, one event, and a result observable to a person or external system.
Tradeoff: The wording becomes more specific and may reveal that several criteria or a smaller story are needed.
The criterion prescribes components, database fields, functions, or test tools
Choose: Keep genuine product constraints in the parent specification and move implementation or test detail to the accountable technical record.
Tradeoff: Readers follow linked records, while the acceptance boundary stays stable across implementation choices.
Important invalid, authorization, retry, conflict, or recovery behavior is missing
Choose: Add the material boundary criteria before marking the set review-ready, and omit irrelevant categories explicitly.
Tradeoff: The set grows only where risk justifies it, avoiding both happy-path blindness and checklist inflation.
A review-ready label is being treated as a passed test or signoff
Choose: Keep criterion review, test execution, UAT decision, Definition of Done, release gates, and target smoke as separate records.
Tradeoff: More identities are maintained, but no drafting label can silently authorize production.
Editable artifact
Start with the observable behavior register
Download the pack, replace the fictional parent references and criteria, then run its validator before review.
Download the acceptance criteria packThe validator checks structure and boundaries. It cannot decide whether a criterion is correct, complete, implemented, or accepted.
Write the parent work item with the user story templateThe user-story owner captures actor, need, value, dependencies, risks, and ready/done boundaries. This resource owns the criterion-level behavior record.
Limits to review before adapting the pack
Consistent criteria can improve shared understanding, but structure cannot prove that the team chose the right behavior or that a later implementation satisfies it.
- The fictional Harbor Lantern parent items, roles, request references, states, provider attempts, dates, and policies are examples, not research, production data, or recommended policy.
- A valid record does not prove that the parent requirement or story is valuable, approved, feasible, safe, complete, small enough, or correctly prioritized.
- Written Given/When/Then statements are not executed tests. Test cases, fixtures, environments, runs, evidence, verdicts, defects, and retests require their own records.
- Review-ready means sufficiently clear for accountable review in this pack. It does not mean passed, accepted, done, deployed, released, or successful.
- Security, privacy, accessibility, legal, compliance, provider, operational, and business-acceptance reviews remain with qualified owners and current evidence.
- This ordinary informational resource is AI-credit-ineligible and does not grant signup AI credits. Product eligibility and plan limits are separate.
Sources and verification record
Current public guidance supports observable, non-implementation-specific criteria, Given/When/Then structure, user-story traceability, and the boundary to shared Done. The same-release artifact supports only the pack described here.
[acceptance-pack] Playcode:Completed fictional acceptance criteria register
Checked August 1, 2026. Supports: The three parent references, ten criteria, eight boundary categories, seven review-ready records, reviewer roles, authority flags, derived views, and local artifact result described on this page. Public availability remains unverified until deployment.
[govuk-better-acceptance] GOV.UK Technology:Creating better acceptance criteria for user stories
Checked August 1, 2026. Supports: Practitioner guidance that acceptance criteria set story boundaries, serve technical and non-technical readers, use simple language, and should remain non-implementation-specific. It does not prescribe this artifact.
[cucumber-gherkin] Cucumber:Gherkin Reference
Checked August 1, 2026. Supports: Current syntax and guidance for Feature, Rule, Scenario, Given context, When event, and Then observable outcome. Gherkin text alone is not evidence that steps were implemented or run.
[cucumber-user-story] Cucumber:User story and acceptance criteria
Checked August 1, 2026. Supports: The boundary between a user story that describes who, what, and why and acceptance criteria that state testable conditions for that story. It does not make Gherkin mandatory for every team.
[govuk-user-needs] GOV.UK Service Manual:Learning about users and their needs
Checked August 1, 2026. Supports: Primary guidance that user needs should be evidence-based and trace forward to constrained user stories with acceptance criteria and dependencies. It does not approve a product requirement or criterion.
[scrum-dod-boundary] Scrum.org:Definition of Done and acceptance-criteria boundary
Checked August 1, 2026. Supports: Practitioner explanation that acceptance criteria apply to a specific story or Product Backlog item while the Definition of Done expresses shared quality for the Increment. It does not prescribe this pack or replace the Scrum Guide.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The published vocabulary named by the machine-readable schema in the pack. Structural validation does not prove product behavior or review quality.
Acceptance criteria template questions
What is a good acceptance criteria format?
Use the smallest format that makes behavior observable. A short outcome rule works for a simple boundary. Given/When/Then works when known context, one event, and the result must be read together. Both need stable parent identity, required evidence, and explicit authority limits in a real workflow.
What is the difference between acceptance criteria and a user story?
A user story captures a specific actor, context, need, value, dependencies, risks, and work boundary. Acceptance criteria state the observable conditions for one reviewed parent item. Link the two by stable ID instead of forcing the full story and every criterion into one unversioned paragraph.
What is the difference between acceptance criteria and a test case?
Acceptance criteria state what behavior would satisfy the product boundary. A test case turns selected criteria into a reusable technical check with fixtures, preconditions, ordered actions, expected results, cleanup, and later run evidence. A written criterion is not a passing test.
What is the difference between acceptance criteria and a test plan?
Acceptance criteria are item-level behavior conditions. A test plan owns the wider QA strategy: environments, data, suites, inventory, traceability, entry and exit gates, defects, retests, recovery, and production smoke. Link criteria into that plan without copying its authority.
Are acceptance criteria the same as the Definition of Done?
No. Acceptance criteria clarify behavior for a specific story or item. The Definition of Done expresses shared quality for the Increment. A team may require both, and neither substitutes for UAT or release authorization.
Who writes and approves acceptance criteria?
Product, business, design, engineering, QA, security, accessibility, and operations contributors may help write and challenge criteria. Keep one accountable product owner for the parent decision and name the reviewer role for each evidence boundary. Local review-ready status is not UAT signoff or release approval.
Does this template grant AI signup credits?
No. This is ordinary informational content with a downloadable artifact. The page is AI-credit-ineligible and does not grant signup AI credits; product eligibility and plan limits are separate.
From reviewed boundary to working evidence
Prototype one bounded outcome in Playcode
After the parent item and criteria are reviewed, use Playcode to build the working app or prototype and gather evidence for the next accountable test and acceptance decision.
Open the AI app builderThis informational article is AI-credit-ineligible and does not grant signup AI credits. Product eligibility and plan limits are separate.