A2.04 · Decomposition
Acceptance, made concrete
A story's Confirmation earns a precise form: a Gherkin scenario, written Given / When / Then. The scenario is the shared, executable definition of done.
A behaviour-driven example sits between intent and test. It is concrete enough that product reads it as a promise, the Operator reads it as the acceptance check, and the Author — the Claude agent — reads it as the behaviour to implement against. One artifact, three readings, no translation. Three dives: the structure, the examples-as-spec, and the path to tests.
One Confirmation, one scenario
The three Cs (A2.02) gave a story a Confirmation — the acceptance check that says when it is done. That check earns a canonical form here: Given (the context), When (the action), Then (the observable outcome). One scenario per behaviour, stated in concrete values rather than abstractions, so “done” is a fact to check rather than an opinion to argue.
Choose a behaviour from the Portal’s value ladder. The figure renders its Given/When/Then scenario from a fixed dataset; the readout names the three clauses. Every rung in the ladder has the same three-clause shape — that regularity is what lets one artifact serve as promise, acceptance check, and build target at once.
A scenario for one Portal behaviour · choose the rung
Write the acceptance criterion as a concrete behavioural example in Given/When/Then, so one artifact serves as promise and as test — one scenario per behaviour.
The enrol rung’s Confirmation is a scenario: Given a learner not enrolled, When they enrol, Then they appear once — read by product, the Operator, and the Author, and run as the rung’s acceptance test.
A Confirmation written Given/When/Then is the shared, executable definition of done — concrete enough to be a promise and a test at once.
The three dives
Each dive takes one move, in the arc structure → shared spec → tests: the three clauses, the examples that are the specification, and the happy and sad paths that become acceptance tests. Read them in order — A2.04.1 starts.
Given / When / Then
The scenario structure: Given sets the context, When is the single action, Then is the observable outcome. One behaviour per scenario, concrete values, not abstractions.
Examples as the spec
The concrete examples ARE the shared definition of done. The Confirmation of the three Cs becomes a scenario — the one artifact product, the Operator, and the Author all read.
Scenarios to tests
Happy and sad paths. Each scenario becomes an acceptance test the Author implements against and the Operator accepts against — the seed of the A4 spec layer and its harness.
A2.04 pins acceptance. The chapter’s later modules — splitting a story too large to estimate, ordering the value ladder, and the workshop that runs the whole pass — build on a story that already carries a checkable definition of done. Return to the A2 module navigation to continue.
References
The behaviour-driven tradition this module draws on, and where it connects in the course.
Sources
- Cucumber — Gherkin reference — the Given/When/Then keywords and the scenario form.
- Adzic, G. — Specification by Example — concrete examples as the shared, executable specification.
- Cohn, M. — User Stories Applied — the Confirmation as a story’s acceptance check.
Related in this course
- A2.04.1 · Given / When / Then
- A2.04.2 · Examples as the spec
- A2.04.3 · Scenarios to tests
- A2.02 · The Connextra form and the three Cs — the Confirmation this builds on.
- A2.03 · INVEST — the Testable story this makes checkable.
- A1.04 · Two layers: roadmap and specs — the spec the scenario pins to.
- Companion · Functional Programming in Elixir — the Portal’s OTP internals.