- Why User Stories?
- User Stories Aren't Use Cases
- User Stories Aren't Requirements Statements
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
User Stories Aren't Use Cases
First introduced by Ivar Jacobsen, [2] use cases are today most commonly associated with the Unified Process. A use case 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. The templates proposed by Alistair Cockburn [3] are among the most commonly used. A sample is shown in Figure 1, which is equivalent to the user story "A Recruiter can pay for a job posting with a credit card."
)
Figure 1 A sample
use case for pay for a job posting.
Within a use case, the term main success scenario refers to the primary successful path through the use case. In this case, success is achieved after completing the five steps shown. The Extensions section defines alternative paths through the use case. Often, extensions are used for error handling; but extensions are also used to describe successful but secondary paths, such as in extension 3a of Figure 1. Each path through a use case is referred to as a scenario. So, just as the main success scenario represents the sequence of steps 1–5, an alternate scenario is represented by the sequence 1, 2, 2a, 2a1, 2, 3, 4, 5.
One of the most obvious differences between stories and use cases is their scope. Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size (such as "no story can be expected to take more than 10 days of development work") so that they can be used in scheduling work. A use case almost always covers a much larger scope than a story. For example, looking at the user story "A Recruiter can pay for a job posting with a credit card," we see that it's similar to the main success scenario of Figure 1. This leads to the observation that a user story is similar to a single scenario of a use case. Each story is not necessarily equivalent to a main success scenario; for example, we could write the story "When a user tries to use an expired credit card, the system prompts her to use a different credit card," which is equivalent to Extension 2b of Figure 1.
User stories and use cases also differ in the level of completeness. James Grenning has noted that the text on a story card plus acceptance tests "are basically the same thing as a use case." By this, Grenning means that the story corresponds to the use case's main success scenario, and that the story's tests correspond to the extensions of the use case.
For example, the following might be appropriate acceptance test cases for the story "A Recruiter can pay for a job posting with a credit card":
Test with Visa, MasterCard, and American Express (pass)
Test with Diner's Club (fail)
Test with good, bad, and missing card ID numbers
Test with expired cards
Test with different purchase amounts (including one over the card's limit)
Looking at these acceptance tests, we can see the correlation between them and the extensions of Figure 1.
Another important difference between use cases and stories is their longevity. Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they're added to the software. While it's possible to archive story cards, many teams simply rip them up.
An additional difference is that use cases are more prone to including details of the user interface, despite admonishments to avoid this tactic. There are several reasons. First, use cases often lead to a large volume of paper, and without another suitable place to put user interface requirements, they end up in the use cases. Second, use case writers focus too early on the software implementation rather than on business goals.
Including user interface details causes definite problems, especially early in a new project when user interface design should not be made more difficult by preconceptions. I recently came across the use case shown in Figure 2, which describes the steps for composing and sending an email message.
)
Figure
2 A use case to compose and send an email message.
User interface assumptions appear throughout this use case: a "New Message" menu item, a dialog box for composing new messages, subject and recipient input fields in that dialog box, and a Send button. Many of these assumptions may seem good and safe, but they may rule out a user interface in which I click a recipient's name rather than typing it to initiate the message. Additionally, the use case of Figure 2 precludes the use of voice recognition as the interface to the system. Admittedly, far more email clients work with typed messages than with voice recognition, but the point is that a use case is not the proper place to specify the user interface in this manner.
Think about the user story that would replace Figure 2: "A user can compose and send email messages." No hidden user interface assumptions. With stories, the user interface will come up during the conversation with the customer.
To get around the problem of user interface assumptions in use cases, Constantine and Lockwood [4] have suggested the concept of essential use cases. An essential use case is one that has been stripped of hidden assumptions about technology and implementation details. For example, the following table shows an essential use case for composing and sending an email message. What's interesting about essential use cases is that the user intentions could be directly interpreted as user stories.
|
User Intention |
System Responsibility |
|
Compose email message |
|
|
Indicate recipient(s) |
Collect email content and recipient(s) |
|
Send email message |
|
|
|
Send the message |
Another difference is that use cases and stories are written for different purposes. Use cases are written in a format acceptable to both customers and developers so that each may read and agree to use case. The purpose of the use case is to document an agreement between the customer and the development team. Stories, on the other hand, are written to facilitate release and iteration planning, and to serve as placeholders for conversations about the users' detailed needs.
Not all use cases are written by filling in a form, as shown in Figure 1. Some use cases are written as unstructured text. Cockburn refers to these as use case briefs. Use case briefs differ from user stories in two ways. First, since a use case brief must still cover the same scope as a use case, the scope of a use case brief is usually larger than the scope of a user story. That is, one use case brief will typically tell more than one story. Second, use case briefs are intended to live on for the life of a product. User stories, on the other hand, are discarded after use. Finally, use cases are generally written as the result of an analysis activity, while user stories are written as notes that can be used to initiate analysis conversations.