User Stories
A user story is a short statement of a need that delivers value to a specific stakeholder: who has the need, what they want to do and why it matters, in a sentence or two. It deliberately does not say everything, because it is a placeholder for a conversation, completed by acceptance criteria as the team approaches delivery. BABOK presents it as one requirements-representation option; the Agile Extension gives it its agile mechanics, its life on a backlog, the INVEST heuristic and the three-C model.
Goal
A user story captures a need at a light granularity and invites exploring it through conversation rather than freezing it in a specification. The card fits in a sentence because it is not meant to carry everything: it identifies a stakeholder, what they want to do and the value they get from it, and it leaves the detail to the discussion that will come as the team approaches delivery.
Almost the whole conduct of an iterative delivery organises itself around this tiny unit. The story is the unit of prioritisation, placed on a backlog that the product owner orders, and the unit the team sizes in order to estimate. Its acceptance criteria become the acceptance test cases. It measures the value delivered, traces the requirements it covers and carries the progress reporting. The deliverable is the story itself, the card and its acceptance criteria living on the backlog, because its value lies in the conversation it triggers, which a frozen document would smother.
The two guides do not frame it the same way. BABOK treats the story as a static requirements-representation artifact, a lightweight means of documentation, and warns that it serves short-term capture, not long-term knowledge retention or a governance baseline. The Agile Extension treats it dynamically, as a placeholder for a conversation that lives on a backlog, and it supplies the two heuristics BABOK does not have: quality, with INVEST, and structure, with the three Cs. Take the first for the definition and the documentary frame, the second for the agile mechanics.
Usage
When to use it
- Iterative, incremental delivery: value ships in slices and priorities shift from one iteration to the next.
- A need to capture without freezing it: catch the stakeholder and their value, then open the conversation rather than freeze a specification.
- A basis for estimating and planning: the story is the unit the team sizes and that is ordered on the backlog.
- Acceptance tests to anchor: the story's acceptance criteria are their direct starting point.
- Value delivered to measure and requirements to trace: the story is the unit linking the need to what shipped and to the progress report.
When not to use it
- Regulatory or safety-critical requirements: the sentence and its conversation leave no durable, traceable record, write a full requirements specification.
- Behaviour rich in alternative paths and exceptions: one line does not carry the flows, reach for use cases.
- Fixed-price engagement without ongoing stakeholder access: the promised conversation will not happen, fix the scope by contract rather than relying on it.
Description
The statement and its elements
The form everyone knows, "as a role, I want goal, so that value", belongs to neither guide. It is the so-called Connextra template, popularised by Mike Cohn in User Stories Applied, and the guides merely relay it. Its strength comes from its third part: the so that, which names the value. The first two parts say who and what, and a classic requirement would stop there; it is the value that turns the statement into a story and that, later, will allow arbitrating between two ways of satisfying it.
BABOK names four elements. The title, optional, an active verb that sums up the story. The statement of value, the core, with the who, the what and the why. The conversation, the discussion about the need between the stakeholders and the team. And the acceptance criteria, which define what will be checked. BABOK lists them; the Agile Extension puts them into tension in a model that explains why a one-sentence card is enough.
The three Cs: the story is a token
The three-C model goes back to Ron Jeffries, who formulated it in the context of Extreme Programming. It holds in three words that all begin with C. The Card is the token: just enough text to identify and remember the requirement. Jeffries gives the test that keeps stories small: if the need does not fit on the card, the card is too big. The Conversation is where the requirement is actually transmitted, over time, between the stakeholders and the delivering team; the card does not say everything, deliberately. The Confirmation is the acceptance criteria, the basis for acceptance, regression and exploratory tests, which confirm that the delivered item satisfies the need.
INVEST: testing a story's quality
INVEST is Bill Wake's acronym, published in 2003, and it is the tool you use to judge whether a story is usable before taking it on. Each letter is a property the story must hold. A story that fails one of them is not a good story, however well written.
| Criterion | What it checks |
|---|---|
| Independent | The story can be delivered on its own, without depending on another's order, which leaves the product owner free to prioritise it. |
| Negotiable | The card is an invitation to discuss: the detail is settled in the conversation. |
| Valuable | It delivers perceptible value to a named stakeholder. It is the "so that" that carries it. |
| Estimable | The team can size it. A story that cannot be estimated is too vague or too large. |
| Small | It fits within one iteration. The Agile Extension restates this "S" as Sized Appropriately; the requirement is the same. |
| Testable | Its acceptance criteria make it possible to decide objectively whether it is satisfied. |
Running the technique
- Identify the stakeholder and the need
The story belongs to someone, and that someone comes from elicitation: a workshop, an interview, field observation. Personas help directly here, because the role at the head of the card is often a persona, and a newcomer's need is not that of a long-standing client. - Write the card
In the who, what, why form, in a sentence or two, with an optional active-verb title. You keep the card short on purpose, because its brevity is what forces the conversation to happen. - Place it on the backlog
The product owner prioritises it against the others. The backlog is an ordered queue that reorders itself each iteration: on every pass the product owner re-ranks what remains against the value expected and what the last delivery taught, so that a story written a month ago can rise to the top or drop to the bottom without ever being rewritten. - Hold the conversation
As delivery approaches, the story is elaborated with the team. That is where you add what execution needs and the card should not have carried: a data model, business rules, a screen mock-up, a state diagram. - Define the acceptance criteria
The Confirmation, often written in the "given, when, then" form. They are defined at the same time as the card: they say what the story really means and they are what makes it testable. - Check INVEST and decompose if needed
A story that is too big or not independent is cut into smaller stories. Story decomposition is the technique dedicated to that splitting; the story mapping session designates the stories that go on to it. - Refine continuously
Backlog refinement is recurring work: stories clarify, re-split and re-prioritise as the team learns.
What makes a story fail
The story written as a task
"As a developer, I want to refactor the payment module" is technical work in disguise, with no stakeholder and no value. A story names a beneficiary and a benefit.
The story too big for one iteration
It violates Small and Estimable and must be decomposed.
The missing "so that"
The Agile Extension names this trap: the team focuses on the feature and drops the value. The value is the story's reason for being.
Acceptance criteria treated as an afterthought
The Confirmation is integral; without it there is nothing to validate against.
The card taken for a complete specification
The Conversation is forgotten, and the token starts claiming the exhaustiveness it never had.
The backlog that swells
Decomposition multiplies stories, and without refinement the backlog rots under its own weight.
Losing sight of the vision
From looking at each story, you stop looking at the product; the roadmap is what keeps the course above the cards.
AI considerations
A model helps with the shaping. You give it an interview transcript, a feature note or a workshop write-up, and you get a first card in the who, what, why form, with a proposed set of acceptance criteria in "given, when, then". It is a starting point to argue with, and it saves starting from nothing. A model does three other concrete jobs. It proposes a split of a too-big story into smaller candidates that the team validates or rejects. It runs a batch of stories through INVEST to flag mechanically the missing "so that", the story written as a task or the statement no one will be able to estimate. And it aligns the cards in French, German and English for a team working in the country's three languages.
The limits are hard and they follow from what a story is. Prioritisation is a business decision: value and frequency are properties of this organisation and its customers, a model has no access to them and forced to decide it will produce a plausible and wrong order. The conversation cannot be automated: the requirement is transmitted between people, and a machine-written card that short-circuits the conversation recreates the exact trap the technique exists to avoid, the card taken for a specification. Acceptance criteria that commit money or compliance are verified with the business: a model invents a threshold, a CHF amount or a deadline that looks right and matches no rule of the house. Finally, interview transcripts and backlogs carry personal data, and they do not go into a public model.
Examples
A physiotherapy practice in French-speaking Switzerland is adding online appointment booking. A patient's need becomes a story whose card, with its acceptance criteria, is the real deliverable.
What the card shows and a line of specification would hide is the "so that". "Book a slot online" is a feature; "so that I do not have to phone during opening hours" is the reason that makes it a priority and that will say, later, whether another solution would do just as well. Without that half, a task remains, with no stakeholder and no value.
The two acceptance criteria are the Confirmation, written in the "given, when, then" form. They say what "booked" really means, they become the test cases and they are the only thing on the card that verifies objectively. The rest is a placeholder for the conversation where the detail will be settled, which cancellation window, which reminder, which language for the email. Measured against INVEST, the story holds: independent of payment, which is another story, valuable to the named patient, small enough for one iteration and testable through its two criteria.
Visualizations
The technique produces one artifact, the story card. These are labelled blocks positioned in space, the statement of value above and the acceptance-criteria band below, which drawing renders better than a list. The three-C model reads the same way, as three linked panels carrying the passage from token to conversation to proof, and it too is drawn. INVEST, by contrast, is made of rows and columns, one per criterion, and what is made of rows and columns is rendered as a table.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | The story assumes an identified stakeholder and a backlog to hold it, nothing more. The heavy work is the upstream elicitation that surfaces the need; the story itself requires no installation, no data to gather, no licence. |
| Execution | Medium | Writing the card takes a few minutes, but its real cost is the conversation and the acceptance criteria, which recur for every story and every iteration, along with continuous backlog refinement. |
| Documentation | Low | The card is deliberately minimal and short-term, so there is little to record. That is also its limit: knowledge that must survive has to be written elsewhere. |
Tooling
The minimum tooling is the index card, with a wall to hold the backlog. The card's physical constraint is a virtue here: what does not fit on it is too big, and the act of reordering cards on a wall is exactly prioritisation. The whiteboard and sticky notes take the same place in a co-located team.
The spreadsheet is enough to hold a small backlog, one row per story, with its priority, its estimate and its criteria. Backlog management tools (Jira, Azure DevOps, GitLab, Trello and the like) take over as soon as the story has to be linked to its estimate, its acceptance criteria, its tasks and the requirements it traces, and as soon as the team is distributed: this is what lets the backlog survive distance, where the wall no longer keeps up.
Specification-by-example tools (Cucumber, SpecFlow and their kind) extend the Confirmation: they run the acceptance criteria written in "given, when, then" as automated tests, which closes the loop between the story and its verification. No tool is required for all that. A card on a wall, with two acceptance criteria written on the back, is a complete instance of the technique.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.48 User Stories: the definition, the list of uses, the four elements (title, statement of value, conversation, acceptance criteria) and the stated limitation, a short-term capture that is worth neither long-term knowledge retention nor a governance baseline.
- IIBA, Agile Extension to the BABOK Guide, §7.21 User Stories: the full agile treatment, the story's life on a backlog, the three-C model, the restatement of INVEST's "S" as Sized Appropriately, the story's management relationships and the traps of the lost "so that", the swelling backlog and the forgotten vision.
- Mike Cohn, User Stories Applied for Agile Software Development, Addison-Wesley, 2004: the Connextra who, what, why template and the framing of the product backlog; the authority behind the story's normative form.
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, 2001: the three-C model and the test that keeps stories small, "if the need does not fit on the card, the card is too big".
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003: the INVEST heuristic, the six properties of a usable story, independent, negotiable, valuable, estimable, small and testable.