← Business and Systems Analysis from Scratch
Lesson
User stories and acceptance criteria (Given-When-Then)
The learner can write a user story in the form 'As a <role>, I want <action>, so that <value>' and add acceptance criteria in Given-When-Then format.
User Stories and Given-When-Then
User Stories and Given-When-Then
A user story is a lightweight way to capture a requirement from the perspective of the person who benefits. The standard template, popularized by Mike Cohn and originating from Connextra, is: 'As a <role>, I want <action>, so that <value>.' Each part serves a purpose: the role anchors who needs the feature, the action states what they need to do, and — crucially — the 'so that' clause explains the business value or outcome. Teams that skip 'so that' risk building features no one actually needs. A quick quality check for the story itself is INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable — a story that fails 'Small' or 'Independent' usually needs splitting.
Acceptance criteria make a story testable. The most widely used format is Given-When-Then, which comes from Behavior-Driven Development (BDD); Gherkin is the plain-text syntax that test tools such as Cucumber use for it: Given describes the context or precondition before the action happens; When describes the specific trigger or action the user takes; Then describes the observable, verifiable outcome. A well-written 'Then' must be objectively checkable — not 'the system responds quickly' but 'the system displays the order confirmation page within 2 seconds'.
There is no fixed number of acceptance criteria, but a story that needs a long list of them is usually too big and should be split. The Given-When-Then format is not just documentation — it can be turned directly into automated tests, which is why developers and testers value it as much as analysts do.
From story to acceptance criterion
- 1Story
As a bank customer, I want to see my balance, so that I can plan my spending.
- 2Given
I am logged in to the mobile app
- 3When
I open 'My accounts'
- 4Then
the balance of each account is shown, as of the last posted transaction
Lesson notes
User Stories and Given-When-Then
A user story is a lightweight way to capture a requirement from the perspective of the person who benefits. The standard template, popularized by Mike Cohn and originating from Connextra, is: 'As a <role>, I want <action>, so that <value>.' Each part serves a purpose: the role anchors who needs the feature, the action states what they need to do, and — crucially — the 'so that' clause explains the business value or outcome. Teams that skip 'so that' risk building features no one actually needs. A quick quality check for the story itself is INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable — a story that fails 'Small' or 'Independent' usually needs splitting.
Acceptance criteria make a story testable. The most widely used format is Given-When-Then, which comes from Behavior-Driven Development (BDD); Gherkin is the plain-text syntax that test tools such as Cucumber use for it: Given describes the context or precondition before the action happens; When describes the specific trigger or action the user takes; Then describes the observable, verifiable outcome. A well-written 'Then' must be objectively checkable — not 'the system responds quickly' but 'the system displays the order confirmation page within 2 seconds'.
There is no fixed number of acceptance criteria, but a story that needs a long list of them is usually too big and should be split. The Given-When-Then format is not just documentation — it can be turned directly into automated tests, which is why developers and testers value it as much as analysts do.