How to Write a User Story

So What is a User Story?

A User Story is used in eXtreme Programming (XP) to define what the customer wants the system to do for them. They replace the traditional requirement specs and use case diagrams.

The Who, the What and the Why

There are many ways to approach writing a User Story. The following approach has worked best for me:-

As [the customer] I want [a capability] so that I can [achieve an outcome]

Its the WHO, the WHAT and the WHY. Who wants this capability, what is it, and why do they want it? It is useful to define the Who and the Why because this makes you consider who wants this feature and what you will achieve with it. If you have difficulty defining either of these, then you probably don't need the feature in the first place.

The Five Whys

To get to the actual, core reason that you require the story, it is sometimes necessary to peel back a few layers. A technique called 'The Five Whys', commonly used to fine root causes of problems, can be useful here. A similar approach can also be applied to finding the actual end-consumer for a story.

Capture the Essence of the Requirement

The Story does not have to, and should not, fully explain every last detail of the requirements. It should be brief, and form a hub for discussion and collaboration. A Story also has acceptance tests and tasks associated with it. The acceptance tests are what fully define the story. To enable you to frame the problem and define the Story to a level where it can be estimated and prioritied, you will probably need a few, high level acceptance tests. You can then get more specific and fine-grained in your tests during development.

Ditch the Jargon

Most Stories should be non-technical, they are capturing a requirement, not the technical implementation of the solution. The alarm bells should go off if there is technical jargon in the Story text. Avoiding describing the solution in the Story also gives you more options, such as solving the problem with a manual process, or a different automated solution that becomes apparent during discussions with developers and testers.

Vertical Slices through the System

It is important that each story represents a slice through the system, eg web page, web service, database. Splitting Stories horizontally, by technical area or layer in the system should be avoided.

Example

As the stock delivery manager, I want to be informed when any stock falls below its threshold level so that I can order more stock in before the store runs out.

Acceptance Tests and Tasks would be added during the Getting the Story Straight and Planning Game sessions.

INVEST in Good Stories, and SMART Tasks
Writing Good User Stories
User Stories