Skip to content
Product Lifecycle Templates

Acceptance Criteria

beta  ·  Family delivery-docs  ·  Phase deliver  ·  Sizes lean, full  ·  ~1,000 tokens

Defines the conditions a user story must satisfy to be accepted, so “done” is verifiable and shared rather than left to interpretation.

Fast reference for the Acceptance Criteria bundle. For the full reasoning, history, and sources, read acceptance-criteria_companion.md.

When to use

Section titled “When to use”
  • To define, before work starts, the conditions that confirm a specific story is done and correct.
  • When QA and engineering need a concrete, shared target.
  • When you want “done” to be a fact, not an interpretation.

When NOT to use

Section titled “When NOT to use”
  • You need a universal, team-wide completion standard. That is the Definition of Done, not AC.
  • You need whole-feature scope, metrics, and non-goals. Use a PRD.
  • The story is so trivial a one-line note suffices. Do not manufacture ceremony.

Pick a variant

Section titled “Pick a variant”
  • Lean (default): a rule checklist plus story reference and scope. For straightforward stories.
  • Full: adds Given/When/Then scenarios, edge cases, and non-functional criteria. For behavior-heavy or risky stories, and when AC will seed automated tests. Grow lean into full by adding sections; never reorder the shared ones.

The rubric

Section titled “The rubric”

Score each 0, 1 or 2. Under 10 out of 14 and “done” will be settled in the review meeting rather than before the work started, which is the one outcome this document exists to prevent.

Which rows apply to what. This bundle ships two variants, and one row grades a section that only the full variant carries, so scoring lean against all seven would penalise the choice of variant rather than the quality of the criteria.

Variant Rows that apply Maximum Score against
full all 7 14 10
lean 1-5, 7 (it carries no Scenarios section) 12 9

Both thresholds sit above two-thirds of the available points; neither is a bare pass mark.

# Criterion 0 1 2
1 Observable outcome, not implementation Criteria name components, technologies or internal mechanisms Mostly behavioural, but at least one criterion says how rather than what Every criterion states something a user could watch happen, and none names a technology
2 Verifiable pass or fail Criteria rest on words like “fast”, “intuitive” or “robust” with no bar Verifiable in principle, but the tester has to choose the bar themselves A tester who has never met the author can mark every criterion pass or fail without asking anyone
3 Unhappy paths covered Happy path only One or two error cases, chosen because they were easy to think of The failure this story is most likely to hit in production is named, with what should happen when it does
4 No overlap with the Definition of Done Restates universal checks such as tests passing or code reviewed Mostly story-specific, with one or two DoD items carried in Every criterion is true of this story and would be meaningless pasted onto the next one
5 Story-specific non-functional bars A bar plausibly applies and none is stated A bar is mentioned without a number or a named standard A number or a named standard scoped to this story, or an explicit statement that none applies and why
6 One behaviour per scenario (full only) One scenario chains several behaviours through repeated “And” steps Scenarios are separated, but at least one “When” contains more than one action Every scenario tests one behaviour and its “When” is a single action
7 Out of scope is stated No scope statement, so a reader cannot tell an omission from a decision Scope stated in general terms Names something a reader would reasonably have expected here and says it is deliberately excluded

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. Implementation, not behavior. “Uses a Redis cache” instead of “loads in under one second.”
  2. Duplicating the Definition of Done. Restating universal checks as story criteria.
  3. Happy path only. No edge or negative cases.
  4. Unverifiable criteria. Conditions you cannot mark pass or fail.
  5. Mega-scenario. One Given/When/Then with many “And” steps testing several behaviors.
  6. Criteria as afterthought. Written after the code, describing what was built, not what was needed.

The artifacts

Section titled “The artifacts”

acceptance-criteria_template-lean.md · ~1,000 tokens

---
title: "{{title}}"
doc_type: acceptance-criteria
size: lean
owner: "{{owner}}"
status: draft
doc_version: "{{doc_version}}"
created: "{{date}}"
updated: "{{date}}"
related_links: []
source_template: acceptance-criteria
source_template_version: 0.1.1
---


<!--
LEAN ACCEPTANCE CRITERIA. A short, rule-based checklist for one story: the conditions that must be
true for it to be accepted. Use this for a straightforward story. To grow it into full criteria, ADD
sections (see acceptance-criteria_template-full.md); never rename or reorder the ones below (the full
variant is a strict superset of this one). Write criteria as observable outcomes, from the user's
point of view, not as implementation steps.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   acceptance-criteria_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a
   WEAK example, and the TRAP to avoid.
2. Replace each {{placeholder}} with your content.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. Before you ship: self-grade against acceptance-criteria_guide.md, then DELETE every HTML comment.
   They are guidance, not content.
-->


# {{title}}


## Story reference


<!-- WHAT  Which user story or backlog item these criteria gate: a link, or the story statement
           itself. Name the user and the goal.
     WHY   AC are meaningless without the story they accept; "accepted into what" must be
           unambiguous. Deep dive: acceptance-criteria_companion.md section 3 (Anatomy > Story
           reference).
     ASK   Which story do these gate? Is it linked or quoted so a reviewer can find it? Are the user
           and goal clear?
     GOOD  "As a recurring analyst, I want to set one of my saved views as the default for a
           dashboard, so that the dashboard opens the way I work instead of in its generic default
           state. (See user-stories_example.md.)"
     WEAK  "Saved views feature." (no user, no goal, no link; a reviewer cannot tell what is being
           accepted)
     TRAP  Free-floating criteria with no parent story. -->


{{story_reference}}


## Acceptance criteria


<!-- WHAT  The rule-based conditions that must hold for the story to be accepted, as a checklist of
           observable, pass/fail outcomes.
     WHY   Discrete rules are clearest as a list, and each must be markable pass or fail; a criterion
           you cannot mark is not finished. Deep dive: acceptance-criteria_companion.md section 3
           (Anatomy > Acceptance criteria).
     ASK   Is each row a single verifiable claim? Could QA mark it pass or fail as written? Is it what
           the user observes, not how it is built?
     GOOD  "Marking a new view as default un-marks the previous default automatically."
     WEAK  "Defaults are stored efficiently in a Redis cache." (implementation detail, not an
           observable outcome the user can verify)
     TRAP  Implementation, not behavior: criteria that describe how it is built rather than what the
           user can observe. -->


- [ ] {{criterion_1}}
- [ ] {{criterion_2}}


## Out of scope and notes


<!-- WHAT  What these criteria deliberately do not cover, plus assumptions and links to adjacent
           stories.
     WHY   It lets a reviewer tell an omission from a decision. Deep dive:
           acceptance-criteria_companion.md section 3 (Anatomy > Out of scope and notes).
     ASK   What did you choose not to cover? What assumptions do the criteria rest on? Where do
           adjacent concerns live?
     GOOD  "Out of scope: team-level defaults (a Team Lead setting a default for everyone) are a
           separate, open decision. Assumes per-user preference storage (shipped Q1)."
     WEAK  Leaving this blank. (silence on scope makes an omission read as a deliberate decision)
     TRAP  No scope statement, so omissions read as decisions. -->


{{out_of_scope_and_notes}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 6 sections across 1 format(s), methodology Agile/BDD, typically owned by Product Owner.