Acceptance Criterion

Origin & evolution

Acceptance criteria grew out of agile and extreme programming, where the user story💬User StoryProduct SpecificationA user's goal and the value they expect, in the "As a… I want… So that…" format. Now also a first-class plannable unit (priority, effort, assignee, due_date) that schedules into a planning_cycle, and it round-trips an external board's column via workflow_state.View reference → was deliberately too small to hold full detail. Ron Jeffries' Card, Conversation, Confirmation formulation (2001) named the missing piece: a story is a card, a conversation about it, and a confirmation that it works. That confirmation is the acceptance criterion, the agreed test that closes the story.

The format that dominates today came from behaviour-driven development. Dan North named BDD around 2003 and described it in 2006 as a way to fix the vagueness of test-driven development. Drawing on the ubiquitous language idea from Eric Evans' Domain-Driven Design, North's collaborators developed the "Given, When, Then" template to capture a story's acceptance criteria in a form business and engineering could both read. By 2007 this had become the Gherkin syntax behind Cucumber, where criteria written in plain structured English could execute as automated tests.

That executable turn changed what a criterion is. A criterion that started as a note for humans became, in Gherkin, both the specification📋SpecificationFoundationsA canonical open standard or specification that primitives and products conform toView reference → and the test, so the document describing correct behaviour and the check enforcing it stopped being able to drift apart. Teams that did not automate kept criteria as written checklists, and the field accepts both, with the trade-off being how easily the criterion goes stale.

Nagy and Rose, in The BDD Books: Discovery, treat that executable artifact as downstream of the work that actually decides correctness. Most BDD writing, they note, bundles conversation, documentation, and automation together; they instead isolate the discovery phase — the collaborative work of agreeing what to build and why before any scenario is written — and argue that a team can produce syntactically correct Gherkin and still encode the wrong behaviour if that upstream work was skipped. Their preferred mechanism is Example Mapping, the card-based workshop (story, rules, examples, open questions) created by Matt Wynne, of which their book is the first full written treatment: it forces a story into concrete rules and examples, surfacing edge cases — such as the unregistered-email decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → above — that a one-line story conceals. On that view the criterion's correctness is settled in the conversation, and the Gherkin only records it.

How it works in practice

A story reads: "As a returning user, I can reset my password by email." On its own that is a wish. The team attaches three criteria. Given a registered email, when the user requests a reset, then a reset link is sent within 60 seconds. Given an unregistered email, when a reset is requested, then the same confirmation message shows and no email is sent (so attackers cannot probe which emails exist). Given an expired link, when it is clicked, then the user is told to request a new one.

The second criterion is the one that earns its keep. It encodes a security decision that the one-line story hid completely, and writing it forced that decision into the open before any code existed. When the work arrives, QA does not interpret intent; they run three checks and the story passes or it does not.

Acceptance criterion vs. its neighbours

• User story states the goal and the user. The acceptance criterion states the conditions that prove the goal was met. The story is the intent; the criteria are the contract that closes it.
• Test case🌵Test CaseQuality AssuranceAn individual test caseView reference → is the concrete, executable verification with specific inputs and expected outputs. A criterion is the condition; a test case is one mechanised way of checking it. One criterion may need🫀NeedUserA user need, pain, desire, or constraintView reference → several test cases to cover its edges.
• Definition of done is a team-wide checklist applying to every story (tests written, reviewed, documented). Acceptance criteria are specific to one story's behaviour. The definition is global; the criteria are local.

In the graph

In the Unified Product Graph, acceptance_criterion✅Acceptance CriterionProduct SpecificationA condition that must be met for a story to be done is a leaf in the Product and Delivery region. It attaches under the story it closes through story_statement_verified_by_acceptance_criterion, and it reaches across into the Operations and Quality region through test_case_validates_acceptance_criterionTest CasevalidatesAcceptance Criterioncross-domain, which links the human-readable condition to the mechanised test that enforces it. That two-edge structure is the executable-specification idea made concrete: the criterion holds the agreed rule, and the connected test case holds the proof it still holds, so a criterion with no validating test is queryably exposed as a promise nobody is checking.