User Stories
A user story is a short description of a need from the user's point of view, written to start a conversation rather than to replace one. The template is the least important part; the skill is slicing work so every story delivers something a user can actually use. This page covers the 3 Cs, acceptance criteria, six ways to split a story, story mapping, spikes and what points are for.
- Origin
- Extreme Programming
- The 3 Cs
- Card · Conversation · Confirmation
- Quality check
- INVEST
A placeholder for a conversation
The familiar template — "As a [role], I want [capability], so that [benefit]" — is a useful default, and it is not what a user story is. It was not in the original idea at all: stories came out of Extreme Programming as index cards with a sentence on them, and the template was invented later at a London company called Connextra as a house style that happened to spread. You are allowed to not use it.
Ron Jeffries described what a story actually is with three words: the Card (a short written reminder), the Conversation (where the real requirement is worked out), and the Confirmation (how you will know it is done). All three are required. A card with no conversation is a badly written specification; a conversation with no confirmation is a disagreement waiting for the review.
That framing has a practical consequence. A story is deliberately under-specified: it holds just enough to remember what to discuss and with whom. A team that treats the card as a complete specification has reinvented the requirements document, with the added handicap that it now has to fit on an index card.
One alternative worth knowing is the job story: "When [situation], I want to [motivation], so I can [expected outcome]". It replaces the persona with a trigger, which is more honest when you do not really know who the user is but you do know exactly when the need appears. Neither format is superior; both are better than a card that says "Search improvements".
Acceptance criteria — the third C
The third C is the one most often dropped. Acceptance criteria are not bureaucracy — they are the answer to "how will we know?", agreed before the work starts rather than argued about at the review. They are also the cheapest possible bug prevention: most of what a tester finds in the first hour is a case nobody discussed.
Two formats cover almost everything. A checklist is a plain list of conditions that must hold — fast to write, easy to read, and the right default for simple stories. Given/When/Then states a starting state, an action and an expected result, which forces you to name the precondition and is the format that translates directly into an automated test.
Keep them few. Three to seven criteria per story is normal; fifteen means the story is really two or three stories, and the criteria list has become the split you have not made yet. Criteria also belong to the story, not to the Definition of Done — the Definition of Done holds what is true of every story (tested, reviewed, deployed), the criteria hold what is true only of this one.
Slice vertically, not horizontally
This is the single skill that determines whether stories help at all. A vertical slice cuts through every layer — interface, logic, storage — and produces something a user can do. A horizontal slice cuts by technical layer and produces nothing anyone can use until the last one lands.
Horizontal slicing is seductive because it matches how teams are often organised and because it feels efficient — the database person does the database part, once, properly. It fails for a reason that has nothing to do with efficiency: nothing is releasable until every layer is finished, so all the feedback arrives at the end, every estimate is unfalsifiable until then, and a slip in the last layer wastes all the layers below it.
Six ways to split a story that is too big
| Split by | Worked example |
|---|---|
| Workflow step | "Check out" becomes: enter address → choose delivery → pay → confirmation email. The happy path first; each later step is its own story. |
| Business rule | Discounts: support a flat percentage now; volume tiers, expiry dates and stacking rules become three more stories. |
| Data variation | Import: CSV first, then Excel, then the bank's fixed-width format. Same flow, one format each. |
| Interface effort | A plain form that works ships now; the drag-and-drop version with live preview is a separate story with its own value. |
| Deferred quality | Make the report correct at 100 rows now; "renders 100k rows in under two seconds" is a separate, measurable story. |
| Operations on the same object | Not "manage saved searches" but create, then view, then rename, then delete. Each is usable alone. |
Story mapping — seeing the whole
A flat backlog of well-written stories has one structural flaw: it loses the shape of the user's journey. Read fifty ordered cards and you cannot tell whether the top twenty add up to something a person can complete. Jeff Patton's story mapping fixes that by laying stories out in two dimensions instead of one.
Across the top runs the backbone: the sequence of things a user does, left to right, in the order they do them — browse, choose, pay, track. Beneath each of those hangs a column of stories, ordered top to bottom by necessity. The map is then sliced horizontally: the top row across all columns is the thinnest version of the journey that works end to end — the walking skeleton — and each row below it is a later release that makes the same journey better.
The value is in what the shape makes obvious. A gap in the backbone is a step nobody thought about. A column with fifteen cards next to columns with two is where the team has over-invested. And a first release chosen by taking the top row is guaranteed to be usable, whereas a first release chosen by taking the top twenty items of a flat list usually is not.
INVEST — a checklist, not a rulebook
| Letter | Means | Fails when |
|---|---|---|
| Independent | Can be built in any order | It cannot start until three others finish |
| Negotiable | The how is still open | The card dictates the implementation |
| Valuable | A user or the business gains something | "Set up the database schema" |
| Estimable | The team can size it | Too unknown — needs a spike first |
| Small | Fits comfortably in one iteration | It has been carried over twice |
| Testable | Done is unambiguous | "Make the app intuitive" |
INVEST is a smell test, not a gate. A story that fails one letter is worth a second look, not an automatic rejection — dependent stories exist, and sometimes the honest answer is to build them in order. The letter worth taking seriously every time is Testable: if nobody can say what would prove it done, no amount of rewriting the other five will save it.
When a story is not estimable: the spike
Sometimes the team genuinely cannot size a story because the unknown is technical — will this library handle our volume, can the vendor's API do partial refunds at all. The answer is a spike: a separate, time-boxed piece of investigation whose deliverable is knowledge, not working software. Two days, a written answer, and the original story becomes estimable.
Two rules keep spikes honest. The time box is fixed in advance and not extended — if two days were not enough, that is itself the finding. And a spike must end in a decision written down somewhere, otherwise the same question gets spiked again next quarter by whoever inherits the code.
Points, and what they are not for
Story points are a relative size, not a duration. The team compares a story against others it has already delivered — this is about twice that one — and the number carries complexity, uncertainty and volume of work together. The reason for using an abstract unit instead of hours is precisely that it cannot be read as a commitment: three points is not three days for anyone.
Velocity — points completed per iteration — is then a forecasting input for the team that produced it, and nothing else. It is not comparable between teams, because the scale is arbitrary and local. It is not a productivity measure, because it is the estimating team's own number: any team measured on velocity can double it in two sprints without changing what it delivers, and every team eventually notices this.
It is also fair to say that many experienced teams stop estimating altogether. Once stories are consistently sliced small, counting them forecasts about as well as summing their points, and the refinement hour goes back into splitting rather than into arguing about whether something is a three or a five. Estimating is a means; if it is not improving a decision anyone makes, it is a habit.
How this shows up in real delivery
The fastest way to tell whether a team writes real stories is to open a sprint and read the titles. If they read "Backend for search", "Search UI", "Search indexing", the team is slicing horizontally and will discover at the end of the sprint that search does not work. If one of them reads "Find a product by exact name", it can ship on its own — and everything after it is an improvement rather than a prerequisite.
The second diagnostic is who wrote them. Stories written entirely by one analyst and handed to the team have skipped the Conversation by construction, no matter how well-formed the cards are. The format survives; the mechanism does not.
Where it degrades
- The template applied to technical tasks — "As a developer, I want a database migration" fools nobody.
- Cards written in full detail so the conversation never happens.
- The "so that" clause dropped, which removes the only reason the story is negotiable.
- No acceptance criteria, so "done" is negotiated at the review under time pressure.
- Fifteen acceptance criteria on one card, which is a split nobody made.
- Story points treated as a productivity target, which inflates estimates rather than output.
- Spikes with no time box and no written outcome, which become side projects.
When to use it
Use it when
- Work can be described in terms of what a user will be able to do.
- The team and the requester can actually talk — the conversation is the deliverable.
- You can release small slices and learn from them.
- Requirements will keep changing, so a negotiable format beats a fixed spec.
Avoid it when
- The work has no user-visible outcome — a library upgrade is a task, not a story.
- A regulator requires a formal, signed specification instead.
- Nobody is available for the conversation, which leaves only the weakest third of the format.
- The template is being applied to satisfy a process check rather than to clarify a need.
Found this useful?
Share it with someone who is working on the same problem.