User story

1. Title: a short name for the piece of work.
2. User: the person who wants this outcome or benefit.
3. Thing: what the user wants (technology-agnostic).
4. Outcome or benefit: why the user wants this thing. No need to capture every reason the user wants the thing—only the most important.

A User Story summarises user requirements, typically for software development, in a single, short, easily-understood sentence that concentrates on the why rather than the how.

User Stories are helpful primarily because they keep the focus on the desired outcome instead of on the solution that might deliver it. This permits the development team the freedom to design a solution without being constrained by preconceived ideas.

• When scoping new work, User Stories are ideal for working out what you need to build, for whom, and why.
• When your client is beginning to dictate solutions, User Stories can help to keep them focused on their needs, rather than on specific system functions and “solutions” (see Tips & Tricks).
• When prioritising work, User Stories help you to prioritise by benefit to the user.

1. Start with the outcome so that everyone is thinking in terms of benefits rather than solutions.
2. Document the desired outcome clearly.
3. Ask the client/user to explain exactly what they want—the thing—rather than rushing to define solutions.
4. Confirm what the thing is in non-technical terms.
5. Finally, establish what the user’s precise role is with regard to the thing. It is not enough to describe them as “users”. Better examples are cashier, manager, buyer, player. Be specific.

• Only ONE expected outcome per story. Focus on the most important outcome—or split the story.
• Only one user per story! Focus only on the most important user.
• Remember that user stories are technology agnostic (see Common issues).

• Use a real user! Avoid writing “as the organisation”.
• Avoid using “and” in the User Story. This usually means that you are hiding complexity.

• Start with the benefit, then work backwards.
• You can validate a business requirement with the User Story construct: “So you want this thing to get that benefit? Is this correct?”
• Users can get attached to ideas! Focus on the desired outcome and you’ll increase the chances that you will actually solve the problem rather than building the first idea that comes along.
• Don’t ignore the user’s ideas for solutions! Just don’t document them in the User Story!

• Story too small. Tiny pieces of functionality in a system don’t usually add up to a measureable benefit that makes the story prioritisable. Having too large a story can also be an issue, but is less common.
• Lazy use of the format. “As a user, I want a submission button so that I can submit my data” isn’t helpful to anyone. There is always a real reason behind a requirement, and a real user who wants it.
• The “user” is the System or a System Admin. As above, this most often means that somewhere there is a real person who wants this functionality for some reason, but no one has found out who or why.
• A vague outcome. It is difficult to be certain that the solution has been achieved if there isn’t a clear outcome against which to measure.
• Designing a solution within the User Story. The biggest benefit to using the User Story format is clarity on what the business wants, so that the development team can collaborate with the business on the most suitable solution that will achieve it. Having a predetermined solution in the User Story inhibits this collaboration and often results in a suboptimal outcome.
• Everything is a User Story! Sometimes requirements don’t fit the User Story format. If that is the case, then don’t use the User Story format!
• Short-sighted stories. It is surprisingly easy to make a User Story all about the person you are talking to, and not about the actual benefit that they are working to achieve. This is the big downside to User Stories: you can get caught up in the immediate problem—which could be personal—rather than focusing on the big picture and the real benefits. It is very rare that the client is paying to make someone’s life easier; most often they are paying to get some business benefit.

Recruiter obtains CVs

As a Recruiter, I want to obtain candidate CVs so that I can determine whether a candidate is suited to the job that I’m seeking to fill.

Save payment information

As an online shop customer, I want to save my payment information so that the checkout process is easier in the future.

Access to leave information

As an employee, I want to know my current leave balance so that I can make realistic holiday plans.

Audit information

As the service owner for product X, I want data changes audited so that I can easily find out who made a change and when it happened.

• Story mapping: document an entire system’s functionality.
• Acceptance criteria: define a feature in yes or no terms.
• Value/effort map: work out what to work on next.