Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories. A user story is a short description of functionality–told from the perspective of a user–that is valuable to either a user of the software or the customer of the software, and typically takes the form of a 3-part template.
A use case, on the other hand, is a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system. Use cases may be written in unstructured text or to conform with a structured template.
Requirements are typically a list of “The system shall…” statements, such as:
- The system shall allow a company to pay for a job posting with a credit card.
- The system shall accept Visa, MasterCard, and American Express cards.
- The system shall charge the credit card before the job posting is placed on the site.
- The system shall give the user a unique confirmation number.
User stories typically (but not always and not in every case) are the best choice for teams using Scrum because they offer several advantages over use cases, requirements, and other options.
Benefits of User Stories
User stories exhibit some of the same characteristics of use cases or traditional requirements statements, but it's the ways in which they are different that give user stories in agile so many advantages.
Benefit 1: User Stories Require Conversations
Perhaps the most important benefit of user stories in agile product development, is that unlike requirements or use cases, user stories are not meant to stand on their own. Instead, each user story is a placeholder for a future conversation with the development team.
The high-level text stored on an index card, Jira issue, spreadsheet cell, or sticky note may be the most visible manifestation of a user story, but it’s not the most important. The most important part of any user story is that a shared understanding of what's needed is worked out in a future conversation.
Benefit 2: User Stories Are Verbal, So More Precise
User stories emphasize verbal communication, so they are more precise. Written language is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way.
We act as though written words are precise, yet they often aren’t. For example, at lunch recently I read this on my menu: “Entrée comes with a 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
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.
Benefit 3: User Stories Are Relatively Easy to Estimate and Prioritize
A third advantage of writing user stories is that they are given estimates that make prioritization and planning go more smoothly. Each user story can be given an estimate of the effort required to develop it; use cases, on the other hand, are generally too large to be given useful estimates.
By the same token, 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.
Benefit 4: User Stories Encourage Teams to Defer Details
A fourth advantage is that user stories encourage the team to defer collecting details.
An initial epic–level story (“A Recruiter can post a new job opening”) can be written, estimated, and placed in the product backlog. It can later be replaced with several, more detailed smaller stories with specific conditions of satisfaction (acceptance criteria) once it becomes important to have those details.
This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen user stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and begin coding much sooner than a team that feels compelled to complete a functional requirements specification.
Benefit 5: User Stories Offer an Overall Understanding of the Product
The fifth advantage is a bit more subtle. Lists of requirements a business analyst might come up with don't give the reader the same overall understanding of a product that user stories do.
It's very difficult to read a list of requirements without automatically considering solutions in your head as you read.
For example, consider the following requirements, adapted from Alan Cooper’s The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How To Restore The Sanity.
- The product shall have a gasoline-powered engine.
- The product shall have four wheels.
- The product shall have a rubber tire mounted to each wheel.
- The product shall have a steering wheel.
- The product shall have a steel body.
By this point, I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible, while I might envision a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.
But suppose that instead of writing an IEEE 830–style requirements specification, stories were written from the user's perspective.
- As a homeowner, I want something that makes it easy and fast for me to mow my lawn.
- As a homeowner, I want a way to mow the lawn where I can sit down rather than stand up.
By looking at goals, we get a completely different view of the product: the customer really wants a riding lawnmower, not an automobile!
Stories describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we can design a better solution to the user’s needs.
Benefit 6: User Stories Suggest a Cost
A final benefit of user stories over requirements specifications is that the cost of each requirement is not made visible until all the requirements are written.
The typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. This document is then handed to the programmers, who tell the analysts (who relay the message to the customer) that the project will take 24 months, rather than the six months they had hoped for.
In this case, time was wasted writing the three-fourths of the document that the team won't have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time.
In good user story practice, an estimate is associated with each story. The customer/product owner knows the velocity of the team and the relative cost of each story, and can quickly decide whether the product they want can be delivered in the time that they have.
Kent Beck told me once that this difference was like registering for wedding gifts. When you register, you don’t see the cost of each item. You just make a wish list of everything you want.
Cost-blind wish lists may work for weddings, but they don't work for product development. When a customer, product owner, or stakeholder places an item on their project wish list, they need to know its cost.
What About You?
What benefits or advantages has your team experienced from writing user stories? Have you experienced any disadvantages? Let me know in the comments below.
