A need arrives messy: half a complaint, half a wish, often wrapped in somebody’s idea of the fix. A user story is one clear sentence the work can be built and tested against. This lesson is the translation between the two, in eight steps.
1. Identify the needs
Start with the needs themselves, anywhere from a high-level goal to one specific pain point. Interviews, surveys, observation and plain conversation with users turn them up.
2. Choose the needs this job meets
Not every need becomes a story in this job. The owner chooses which needs this job meets, by what the business needs first, and the rest are written down for a later job, so nothing is lost and nothing is built unasked.
3. Say what changes for them
Before writing a story, say what changes for the person with the need once it is met, such as a customer who no longer calls to ask what has sold out. That change becomes the story’s “so that”.
4. Use the template
One template keeps a story short and buildable: “As a [type of user], I want [an action] so that [benefit/value].” Each part answers one question: who it is for, what they do and why it matters to them.
5. Add acceptance criteria
Acceptance criteria are the conditions under which the story is done. Without them, “done” is whatever the last person to read the story thinks it is; with them, building and testing aim at the same mark.
6. Keep it small
A story should be small enough to name as one line in the written scope and finish within one iteration. Small stories are easier to estimate, build and test.
7. Work it out with the owner and the users
Stories are written together, by the owner who signs the written scope, the webmasters on the job and the people who will use the result. The owner reads the stories before the scope is signed, and the webmasters say what each one would take, so everyone works from one reading.
8. Refine as you learn
Refine each story, and its acceptance criteria with it, as the project teaches you more about the need.
Example user story
“As a customer with an account, I want to reset my password so that I can regain access to my account.”
- User: Customer with an account
- Action: Reset my password
- Benefit/value: Regain access to my account
Example acceptance criteria
- Asking for a reset sends a reset link to the email on the account.
- The reset form shows the same message, in the same time, whether or not the email belongs to an account.
- The reset link works once and expires after 24 hours.
- After the reset, the new password signs in and the old one no longer does.
In the code, a criterion like the 24-hour expiry becomes a pure function of the link’s age, with the clock read at the edge; the lecture What Is a Function? shows that boundary.
To try it, take one need from your own week, such as the customers who call to ask what has sold out, and walk it down the diagram: if a setting, a procedure or training meets it, write that down instead; if software has to change, write the story and two criteria a test could fail.
Translation takes empathy, plain talk and a working knowledge of how software gets built. Practiced, it gives every story a need someone stated, in words they can check.
The next lesson, on writing clear and concise user stories, takes a story nobody can build or test, “As a user, I want the site to be easier to use”, and rewrites it until the owner and every webmaster picture the same thing.