What is a user story, and what does its role-goal-benefit shape buy a team?
answer
- who wants it, and why
- not a specification
- a placeholder for a conversation
- card, conversation, confirmation
- acceptance criteria carry the detail
basics
~20 sA user story is a short, user-facing description of a wanted change, written as who wants it, what they want to do, and why. The shape is a placeholder for a conversation, not a finished specification.
solid answer
~50 sA user story names a **role**, the **capability** that role wants, and the **benefit** they expect — for example, a returning patient who wants to see the next open slots with their usual hygienist so they need not phone the desk. The value is not the template but what it forces: the item must be expressed as an outcome for somebody, so the team can ask whether that outcome is worth building at all. A story is deliberately incomplete — it is a **placeholder for a conversation** between the people who want the change and the people who will build it. The detail arrives afterwards as **acceptance criteria**: the concrete, checkable conditions that say when this particular item is satisfied. An item that cannot be phrased as a benefit to anyone is a signal worth raising, not a template to fight.
code
pseudocode · 13 linesSTORY
As a returning patient
I want to see the next three open slots with my usual hygienist
So that I can rebook without phoning the desk
ACCEPTANCE CRITERIA
- Given the patient has a past appointment,
when they open rebooking,
then the three earliest open slots for that hygienist are shown
- Given that hygienist has no open slot within 60 days,
then the next available colleague is offered instead
- Given the patient has no past appointment,
then the general availability list is showngo deeper
Be ready to write one on the spot from a plain feature request, and to say what the benefit clause is for. Interviewers accept an imperfect story; they do not accept a candidate who cannot say who the item is for.
Explain card, conversation and confirmation, and show how acceptance criteria make an item checkable without turning it into a specification. Be able to say why a story is deliberately left incomplete when it is written.
Expect to be pushed on items the template does not fit — enabling work, defects, timeboxed investigations — and to defend keeping the question behind the shape while dropping the costume. Show how you keep stories from silently becoming specifications.
Own the argument that a list of stories is not a contract. A stakeholder asking for fixed scope signed off is asking the format for a guarantee it cannot give, and the useful counter-offer is a visible order of delivery.
## What a user story is A **user story** is a single item on a Product Backlog, written from the point of view of somebody who benefits from it. The conventional shape names three things: the **role** (who wants this), the **goal** (what they want to be able to do) and the **benefit** (why that is worth having). A booking product for a dental clinic might carry: *as a returning patient, I want to see the next three open slots with my usual hygienist, so that I can rebook without phoning the desk.* The template is not the value. Teams that treat it as a form to fill in produce items like *as a user, I want a dropdown, so that I have a dropdown* — grammatically a story, worth nothing. The value is that the shape makes it awkward to write down work with no beneficiary. Every item has to answer "for whom, and what can they do afterwards?" An item that cannot answer is usually one of two things: enabling work that should be attached to the outcome it unlocks, or work nobody has justified yet. ## The three clauses and what each one guards against | Clause | Question it answers | What its absence lets through | | --- | --- | --- | | Role | Who is this for? | Work with no identifiable beneficiary | | Goal | What can they do afterwards? | A chosen solution smuggled in before the need is understood | | Benefit | Why is that worth building? | Items nobody can order, because their value was never stated | The benefit clause does the most work and is the one most often filled with noise. "So that the system is better" is not a benefit. "So that I can rebook without phoning the desk" is, because it is falsifiable — you can put it in front of a patient and find out whether it happened. ## Card, conversation, confirmation A durable way to describe the practice is three C's: 1. **Card.** The story is short enough to fit on a card. That is a limit on how much is written down in advance, not a claim that the card is complete. 2. **Conversation.** The actual requirement is worked out by talking — the person who wants the change, the people who will build it, and whoever will check the result. 3. **Confirmation.** What the conversation settles is written as **acceptance criteria**: the specific, checkable conditions under which *this* item is satisfied. This is why a story is best understood as a placeholder for a conversation. Written detail decays, and written detail is expensive; a short card plus a conversation held close to the moment of building is cheaper and more accurate than a specification written months earlier. Acceptance criteria belong to one item and are negotiated item by item. They are not the same thing as the team-wide quality standard that every finished item must meet whatever it contains — that standard is uniform and shared, while acceptance criteria differ from story to story. ## Writing them so they help - Keep the goal clause in the user's language, not the implementation's. - One story, one outcome. Two "and"s in the goal clause usually means two stories. - Make the benefit falsifiable, so somebody could later say whether it happened. - Do not smuggle in the design: "I want a way to rebook" leaves room, "I want a dropdown" does not. - Expect the wording to change. An item that has sat untouched for 14 months near the bottom of the list is usually stale, not stable. - Let the acceptance criteria carry the precision, and keep the card short. ## Where the shape does not fit Not everything on a Product Backlog is a user story, and forcing the costume produces the *as a developer, I want...* items that give the practice a bad name. Items that legitimately look different include: - **Enabling work** with no directly visible outcome — attach it to the story it unlocks, or state its purpose honestly in ordinary prose. - **Defect reports**, which already describe the gap between expected and actual behaviour. - **Timeboxed investigations**, whose output is a decision rather than a capability. - **Obligations imposed from outside**, where the beneficiary is the organisation rather than a user. The rule worth keeping is not the template but the question behind it: who is better off, and how would we know? ## The fixed-scope conversation A customer who wants scope fixed in advance will read a list of stories as a contract and ask for it to be signed. It cannot be one, and pretending otherwise is where the practice usually breaks. The honest position is that the **acceptance criteria of the items being built next** are a commitment, the ordering below that is an intention, and the wording of the item at position 37 is a note about a conversation nobody has had yet. Teams that say this early end up negotiating about the order of delivery, which is a real thing to negotiate; teams that say it late end up defending a sentence written 14 months ago as though it were a specification.
- An item is pure enabling work with no visible beneficiary. How do you write it?Do not force the template — an item reading *as a developer, I want a queue* helps nobody. Either attach the work to the story it unlocks, so the outcome carries it, or write it in plain prose with an honest statement of what it makes possible and what it costs. Keep the question the template asks, even when you drop the template: who is better off afterwards, and how would we know?
- What separates the acceptance criteria from the story text itself?The story text says who wants what and why; it is short, negotiable and written before anyone knows the detail. The acceptance criteria are the checkable conditions agreed in conversation nearer the build, and they are what makes the item verifiable. The story is the invitation to talk. The criteria are what the talk concluded, specific to this item rather than a standard applied to every item alike.
- A customer asks you to sign off the story list as fixed scope. What do you tell them?That the list is not the kind of artefact that can be signed. What can be committed is the acceptance criteria of the items being built next, and what can be offered is a visible order of delivery. An item near the bottom is a note about a conversation nobody has had yet — signing it converts a placeholder into a promise, and the first refinement conversation will break it.
The card is a note in a diary reminding two people to talk. The conversation is where the real detail is agreed, and the acceptance criteria are the minutes.
saying these in an interview costs you the question
- Treats the template as mandatory for every backlog item
- Says the story is the specification and needs no conversation
- Writes the solution into the goal clause: 'I want a dropdown'
- Leaves the benefit clause as 'so that it works better'
- Confuses per-item acceptance criteria with the team-wide quality standard