A friend recently asked me if I had any advise on how to write user stories (opens in a new tab). While I don't claim to be an expert on writing user stories, I knew enough to guide him. Here's what I came up with.
Why User Stories?
User stories are a terse requirements format that puts emphasis on conversations rather than comprehensive documentation. User stories are the preferred requirements format for Agile (opens in a new tab) software development projects. Other requirements formats, like use cases (opens in a new tab), attempt to provide a definitive requirements definition. Unfortunately, due to their verbose nature, they do not allow for changes to the requirements that are discovered over time. User stories excel at this.
The 3 C's
Ron Jeffries (opens in a new tab) defines 3 C's (opens in a new tab) which are the critical aspects of a user story:
- Card - user stories should be written on a card. This helps keep them small. The card serves a placeholder for the conversation. The card is what is used during release planning (opens in a new tab).
- Conversation - as previously stated, a user story puts emphasis on having a conversation between the customer and the programmers. Ron points out that these conversations can be supplemented by documents, and the best documents at examples.
- Confirmation - this refers to the acceptance criteria or test for each user story. The customer should communicate the acceptance tests prior to development. The best type of confirmation for a user story is an example, and preferably automated.
User Story Format
User stories traditionally conform to the following format:
As a <type of user>,
I want <some feature>,
So that <some reason or business value>
Most agile experts would agree that the most important part of a user story is the last line, which defines the business value. Since this the most important line, I tend to prefer Elizabeth Keogh (opens in a new tab)'s user story format (opens in a new tab), that looks like this:
In order to <some reason or business value>
As a <type of user>,
I want <some feature>
This format places the business value statement first. When writing a ne story, you are forced to think about the business value before the feature.
INVEST
The INVEST (opens in a new tab) model is a way of evaluating the quality of a user story. Here's what it stands for:
- Independent - a user story should not be dependent upon another story.
- Negotiable - the details of the story will be worked out during the conversation. Talk about the story before working on it.
- Valuable - the user story needs to be valuable to the customer or user.
- Estimable - the estimation need not be perfect, but good enough so you can rank and schedule a story.
- Small - small is good. Small is easier to estimate.
- Testable - make sure that you can validate the user story is done. Write tests!
Further Reading
For more information on user stories, I highly recommend these resources. I especially recommend Fadi Stephan (opens in a new tab)'s (a fellow Excellain (opens in a new tab)) great presentation, the Art of Storytelling (opens in a new tab).
- Michael Cohn on User Stories (opens in a new tab)
- Wikipedia on User Stories (opens in a new tab)
- Extreme Programming on User Stories (opens in a new tab)
- Ron Jeffries on the 3 C's (opens in a new tab)
- Elizabeth Keogh on User Story Format (opens in a new tab)
- Dan North on User Stories (opens in a new tab)