Advantages of User Stories over Requirements and Use Cases

Extreme programming introduced the practice of expressing requirements as 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. User stories often use a three-part template:

As a [type of user], I want [some goal], so that [some reason].

A use case is a generalized description of interactions between a system and one or more actors. An actor may be a person, another system, or something else that interacts with the system. Use cases can be written informally, but many teams write them using a structured template.

Requirements are often written as 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 documents, and other ways of describing product work.

Benefits of User Stories

User stories share some characteristics with use cases and traditional requirements statements. But the differences are what make user stories so useful on agile projects.

Benefit 1: User Stories Require Conversations

The most important advantage of user stories is that they are not meant to stand on their own.

A user story is a placeholder for a future conversation. The text stored on an index card, sticky note, Jira issue, spreadsheet cell, or backlog item may be the most visible part of a user story, but it is not the most important part.

The most important part is the shared understanding created through conversation.

A written requirement can give the illusion that everyone understands the same thing. A user story makes the need for conversation explicit. The product owner, team members, stakeholders, and others talk about what is needed, why it matters, what tradeoffs are acceptable, and what must be true when the story is done.

Benefit 2: User Stories Help Teams Discover Ambiguity

User stories emphasize conversation, and conversation helps teams find ambiguity sooner.

Written language often seems precise when it is not. A customer and a developer can read the same sentence and leave with different interpretations.

I saw a simple example of this at lunch recently. The menu said:

Entrée comes with a choice of soup or salad and bread.

That should have been easy to understand, but it was not. Did it mean I could choose:

• Soup or (salad and bread)
• (Soup or salad) and bread

The waitress removed the ambiguity with a simple question: “Would you like soup or salad?” She removed the rest of it by placing a basket of bread on the table before taking my order.

That is the value of conversation. Ambiguity that remains hidden in written text often becomes obvious when people talk.

Benefit 3: User Stories Are Easier to Estimate and Prioritize

User stories are usually easier to estimate and prioritize than use cases or long lists of requirement statements.

A user story can be given an estimate of the effort required to develop it. Use cases are often too large to estimate usefully.

Requirements documents create a different problem. A typical software requirements specification may contain thousands or tens of thousands of statements, plus relationships among those statements. Prioritizing at that level is difficult.

When requirements can only be prioritized as high, medium, or low, they are not well suited to an iterative and incremental process that delivers working software every few weeks.

User stories give the product owner and team smaller units of work to discuss, estimate, order, split, and deliver.

Benefit 4: User Stories Encourage Teams to Defer Details

User stories help teams defer detail until the detail is useful.

An initial epic-level story, such as “A recruiter can post a new job opening,” can be written, estimated, and placed in the product backlog. Later, when the work moves closer to implementation, that large story can be split into smaller stories with specific conditions of satisfaction or acceptance criteria.

That makes user stories well suited to time-constrained projects. A team can quickly write a few dozen stories to get an overall feel for the product. Then the team can add detail to the most important stories and begin building sooner than a team that feels compelled to complete a full functional requirements specification first.

Benefit 5: User Stories Give a Better View of the Product

Lists of requirements do not usually give the reader the same overall understanding of a product that user stories do.

It is hard to read a list of requirements without immediately thinking about a solution. For example, consider these requirements, adapted from Alan Cooper’s The Inmates Are Running the Asylum:

• 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, you may be picturing an automobile. An automobile satisfies those requirements. You might picture a red convertible. I might picture a blue pickup. Presumably, the differences between your convertible and my pickup would be addressed in additional requirements.

But suppose the team had written stories from the user’s perspective instead:

• 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.

Now we have a completely different view of the product. The customer wants a riding lawnmower, not an automobile.

Stories describe user goals. By focusing on those goals rather than a list of product attributes, teams are more likely to design a solution that fits the real need.

Benefit 6: User Stories Make Cost Visible Earlier

A final advantage of user stories is that the cost of each desired capability can become visible earlier.

With a traditional requirements document, the typical scenario is that one or more analysts spend two or three months, and often longer, writing a lengthy document. That document is then given to the programmers, who tell the analysts, who tell the customer, that the project will take 24 months instead of the six months everyone had hoped for.

By then, a lot of time has been spent writing detail for functionality the team will not have time to build. More time will be spent deciding what to remove.

With user stories, an estimate is associated with each story. The customer or product owner can compare the relative cost of each story with the team’s velocity and make better decisions about what can fit in the available time.

Kent Beck once told me this difference is like registering for wedding gifts. When you register, you do not see the cost of each item. You just make a wish list of everything you want.

Cost-blind wish lists may work for weddings. They do not work for product development.

When a customer, product owner, or stakeholder adds something to a product wish list, they need some sense of its cost.