Writing User Stories

May 04, 2012

Photo credit: https://www.flickr.com/photos/spacex/44451125454/

A friend recently asked me if I had any advise on how to write user stories.  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 software development projects.  Other requirements formats, like use cases, 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 defines 3 C's 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.
  • 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's user story format, 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 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's (a fellow Excellain) great presentation, the Art of Storytelling.

Share this:

comments powered by Disqus