Advantages of User Stories for Requirements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.