User Stories for Requirements
BA Forum Moderator
By Mike Cohn.
Article is provided courtesy of Prentice Hall PTR.
Date: Oct 8, 2004.
At the surface, user stories appear to have much in common with use
cases and traditional requirements statements. However, there are many
subtle differences among them and many advantages to user stories,
especially for agile development projects.
Some ideas in this article are derived from Mike Cohn's book User
Stories Applied: For Agile Software Development (Addison-Wesley, 2004,
ISBN 0321205685).
Extreme programming (XP) introduced the practice of expressing
requirements in the form of user stories, short descriptions of
functionality-told from the perspective of a user-that are valuable
to either a user of the software or the customer of the software. The
following are typical user stories for a job posting and search site:
A user can post her resume to the web site.
A user can search for jobs.
A company can post new job openings.
A user can limit who can see her résumé.
But user stories are not just these small snippets of text. Each user
story is composed of three aspects:
Written description of the story, used for planning and as a reminder
Conversations about the story that serve to flesh out the details of
the story
Tests that convey and document details that can be used to determine
when a story is complete
Because user story descriptions are traditionally handwritten on paper
note cards, Ron Jeffries has named these three aspects with the
wonderful alliteration of card, conversation, and confirmation. [1] The
card may be the most visible manifestation of a user story, but it's
not the most important. While the card may contain the text of a story,
the details are worked out in the conversation and then recorded and
verified through the confirmation.
Why User Stories?
Because stories exhibit some of the same characteristics of use cases
or traditional requirements statements, it's important to look at what
distinguishes stories from these earlier requirements techniques. These
differences can lead to many advantages for user stories.
Let's Be Precise
User stories emphasize verbal communication. Written language is often
very imprecise, and there's no guarantee that a customer and developer
will interpret a statement in the same way. For example, at lunch
recently I read this on my menu: "Entrée comes with choice of soup or
salad and bread."
That should not have been a difficult sentence to understand, but it
was. Which of these did it mean I could choose?
Soup or (salad and bread)
(Soup or salad) and bread
We act as though written words are precise, yet they often aren't.
Contrast the words written on that menu with the waitress' spoken
words: "Would you like soup or salad?" Even better, she removed all
ambiguity by placing a basket of bread on the table before she took my
order.
As another example, I recently came across this requirement, referring
to a user's ability to name a folder in a data management system: "The
user can enter a name. It can be 127 characters." From this statement
it's unclear whether the user must enter a name for the folder. Perhaps
a default name is provided. The second sentence is almost completely
meaningless. Can the folder name be other lengths, or must it always be
127 characters?
Useful for Planning
A second advantage of user stories is that they can be used readily in
project planning. User stories are written so that each can be given an
estimate of how difficult or time-consuming it will be to develop; use
cases, on the other hand, are generally too large to be given useful
estimates. Also, a story is implemented all in a single iteration of an
agile project, while it's common to split a use case across multiple
iterations (even though those iterations are usually longer than on a
story-driven project).
IEEE 830-style requirements statements ("The system shall...")
represent a different problem. When you consider the thousands or tens
of thousands of statements in a software requirements specification
(and the relationships between them) for a typical product, it's easy
to see the inherent difficulty in prioritizing them. If the
requirements cannot be prioritized beyond the common high, medium, and
low, they're unsuitable for a highly iterative and incremental
development process that will deliver working software every two to
four weeks.
Spare Me the Details
Stories have additional advantages, but I'll provide only one more.
User stories encourage the team to defer collecting details. An initial
place-holding goal-level story ("A Recruiter can post a new job
opening") can be written and then replaced with more detailed stories
once it becomes important to have the details. This technique makes
user stories perfect for time-constrained projects. A team can very
quickly write a few dozen stories to give them an overall feel for the
system. They can then plunge into the details on a few of the stories
and can be coding much sooner than a team that feels compelled to
complete an IEEE 830-style software requirements specification.
Continuation of the article may be read from:
http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=2