Use Cases or User Stories?

by Gary K. Evans

In 1992 Ivar Jacobson introduced a new requirements technique known as use cases. Within 10 years another technique - user stories - gained mind-share. Then the debate began: Which is better? Which provides more value? This month I want to explore both practices.

User Stories

A user story is a simple, and invariably small, statement of functionality that provides value to an end-user. Here are some user stories from a Vehicle Rental system:

• As a customer, I can reserve a vehicle.
• As a customer, I can apply a discount program to my reservation.
• As a customer, I can specify selection criteria for vehicle search.
• As a Customer Service Representative, I can make a reservation for a customer.
• As a Customer Service Representative, I can apply a discount program to a reservation.
• As a Garage Representative, I can exchange a vehicle for a customer.

The user story format is very sparse: "As a <user>, I can <identify the value to be obtained> ". The simplicity of this structure is often an obstacle for those who assume the user story is a complete specification of a requirement. It is not. The user story is:

1. A brief statement of value to be provided the end-user, and
2. A "placeholder" for discussion about the real requirements, not a replacement for requirements.

Use Cases

A use case is different. The IBM/Rational Unified Process (RUP) defines a use case as "A sequence of actions a system performs, that provide observable value to a particular actor", where actor in this definition represents a user.

The goal of a system-level use case is to describe the interactions that take place between the user and the system as the system meets the user's goal: for example, completing a vehicle reservation, or exchanging a vehicle. Specifically, a use case documents a process consisting of these interactions.

Here is an example use case from the Vehicle Rental system (showing only the "happy path" where nothing goes wrong):

Use Case: Reserve a Vehicle

1. System prompts the customer for the pickup and return locations of the reservation, and the pickup and return dates and times.
2. Customer indicates vehicle selection criteria. The default is to search for all categories of vehicles.
3. System returns matching vehicles, with their base rates.
4. Customer selects a vehicle.
5. System prompts for customer's Frequent Renter identification number.
6. System obtains the customer's rental profile, which the system retains to pre-populate any required information.
7. System prompts for desired protection product coverages, other amenities (car seats, GPS device, etc), and desired discount programs (AAA, etc.).
8. System presents estimated total cost of reservation.
9. Customer approves cost.
10. Customer provides payment information and system obtains payment satisfaction.
11. System presents confirmation number to customer.

Use Cases, or User Stories?

We can draw some interesting conclusions just from these simple examples.

First, we see that some user stories could expand to complete use cases (complex processes). The user stories

• As a customer, I can reserve a vehicle
• As a Customer Service Representative, I can reserve a vehicle for a customer

are both represented in more precision and complexity in the use case above. But the user stories allow us to talk about "reserving a vehicle" without having to carry around all of the use case complexity.

Second, we see that some user stories are appropriately steps of a larger, encompassing process described by a use case. These user stories:

• As a customer, I can specify selection criteria for vehicle search.
• As a customer, I can apply a discount program to my reservation.

are steps 2 and 7, respectively, in the use case above.

Third, while the user story is a simple "shorthand" for value the end user wants, the use case describes the process that provides this value for the end user.

Fourth, use cases provide an immediate context for specification of the system behavior when some obstacle or exception is encountered. Here are two exceptions that could occur at step 3 and step 5, respectively, of the use case:

3a. No matching vehicles
This alternate occurs if no vehicle matches the location and dates provided by the Customer.

3a.1 System informs customer no vehicles found matching the location and dates provided by customer.
3a.2 Go to Step 2.

5a. Customer does not provide Frequent Renter number
This occurs if the customer either does not have a Frequent Renter number, or just does not provide her number.

5a.1 System prompts for required customer information (e.g., name, address, birth date, license number, license state, etc.).
5a.2 Go to Step 7.

In my experience, user stories do not readily create the process context that joins these exceptions with the "happy path" in the single, integrated format that a use case provides. In contrast, the user story's brevity and purposeful lack of precision forces us to explore with our end users the actual requirements surrounding the goal of the user story.

The issue is not "either/or": either use cases or user stories. Rather, we should take a view of "both/and": both use cases and user stories provide a more complete view of the end user goals our software must achieve.

Have a productive month,

    Gary K. Evans