User stories are the building blocks of user-centric software: a feature in one sentence, told from the side of the person who uses it. Here are the three parts that make one work, and the three habits that keep it a story.
The three parts
Who: the user’s perspective
A story is written from the user’s side and opens with “As a [type of user]…”, so from its first words everyone knows who the feature is for.
What: the user’s action
The heart of the story is what the user wants to do, starting “I want to…” or “I need to…”. Name one thing the user does, such as “see what has sold out today”, rather than a goal as broad as “use the menu”.
Why: the benefit or value
“So that…” or “in order to…” says what the user gains from the action: the reason behind the request, and the yardstick every solution is measured against.
Three habits of a good story
Independent
Each story stands on its own as one distinct need, so it can be ordered, sized and built by itself.
Small
A story is small enough to build and check in one piece; a larger one is split by its acceptance criteria, as the end of this lesson shows.
Not prescriptive
“A dropdown of my orders” is a solution; “see my past orders” is a need. Write the need, and the team is free to find the best way to meet it. Technical detail belongs in the work, not in the sentence.
An example
“As a customer, I want to view my order history so that I can track my past purchases and check the status of current orders.”
In this example:
- User perspective: The user is a “customer.”
- User action: The user wants to “view my order history.”
- Benefit or value: The benefit is to “track my past purchases and check the status of current orders.”
Its acceptance criteria
- The customer can open their order history from their account.
- The order history lists past purchases, each with its order date, items and status.
- Each order in the history opens to show its details.
Acceptance criteria say when the story is done, and they guide the building and the testing. On the Sean Dinwiddie’s Webmastery team, a story with more than one criterion, as this one has, can take each as a Rule, shown by one or more Given, When, Then scenarios: Given a customer with two past orders, When they open their order history, Then both orders are listed with date, items and status.
A story with all three parts says who the work is for, what they do and why it matters to them, and its acceptance criteria say when it is done. The lecture Redux Toolkit and Functional Programming shows where a criterion like these ends up in a custom app: a test that runs a slice through its events and checks what a selector returns.
To try it, write one request from your own week, such as “add a menu page”, as who, what and why. If the why only repeats the what, the need is still hiding: the next lesson, on identifying user needs, finds it before a story is written.