User Stories vs. Use Cases

Special note on Listening: we do listening in two ways:

UserStories. (Similar to ˜use cases .) On cards, our customers write stories describing how something is supposed to work. A story might say ˜An employee making $10 an hour works four hours of overtime on Friday and two on Sunday. She should receive $60 for the Friday overtime and $40 for Sunday. We have hundreds of cards describing the product.

Acceptance Tests. These are typically single use cases with expected answers provided by the customer. ^[6]
”Ron Jeffries

User stories are often compared with use cases, partly because they have similar names , but ultimately because they re there to achieve the same thing: Define the system requirements in terms of what the users do. However, as we explore in this section, the similarities pretty much end there.

Jeffries comparison of user stories with use cases is quite erroneous, because use cases represent only behavioral requirements, which is what you d think a user story would be. Unfortunately, user stories aren t defined that tightly. User stories are vaguely defined as whatever notes you make on the index card. That can include behavior requirements, functional requirements, and just about anything else you can think of, such as requests for documentation.

Stories are often equated with use cases (even by Mr. Jeffries, as in the previous-quote). So let s compare the two (later we compare stories with requirements).

The Use Case

Before we get started comparing user stories with use cases, let s quickly define what a use case is, and then describe how it s used in use case “driven development.

A use case defines discrete system behavior of value to a particular actor (user role). The best use cases are those written in active voice, in present tense, in terms of user action/system response ( the user does this; the system responds by doing that ), and unambiguously using the terms defined in an accompanying glossary or domain model.

A single project may have hundreds of use cases defined. Because the use case defines external system behavior (as observed by the user), it doesn t make inroads into design. In other words, it defines the what of a system (as in, what do we want this system to do?) rather than the how (as in, how shall it do it?).

A use case scenario is a specific example ”an instance of a use case. The sunny-day scenario is the normal case: What happens if the user does exactly what is expected and completes the transaction? The rainy-day scenarios (of which there are usually many) are variations on the use case (e.g., the user tries to perform a task for which she isn t authorized).

What Is Use Case “Driven Development?

Although it s not our purpose to explain use case “driven development completely in this book (there are already a couple of pretty good books on the topic ^[7] ), it s at least worth explaining to the level of detail that it can be compared to the XP approach.

In use case “driven development, the major steps for designing a scenario are as follows :

Write a couple of paragraphs of English that explain the behavior, including both sunny-day and rainy-day (exceptional) usage paths.
Identify the objects that will participate in the scenario.
Assign responsibility for specific operations to the appropriate classes.
Code it.
Test it.

In XP, as in use case “driven development, programmers are working on one story (loosely speaking, analogous to a use case scenario ”at least it might be, depending on the kind of story you ve got). In XP, you ll also identify participating objects and assign responsibility for operations to classes, but you do all this as the code is being written. And in XP, those nasty special cases (exceptional behavior) can be dealt with by saying YAGNI and DTSTTCPW. So it looks like you re getting done real fast, initially. But that s because you ve swept the problematic stuff under the rug.

For an example of this phenomenon in action, see the section Generate a Quick Illusion of Success in Chapter 2.

The programmers write some tests for each operation being coded and then code it. The overall responsibility for making sure all the exceptional conditions from a system usage standpoint are handled in acceptance testing ”that is to say, they are pushed off to the customer.

In use case “driven development, the use case text is written in the context of a domain model, which is something like a combination of XP s metaphor and an early stab at a core object model/architecture, focused on the problem domain. And, in use case “driven development, the object model is evolved in the abstract for a group of scenarios (whatever is in your current iteration) in parallel, before the classes are committed to code. And this object model rigorously takes into account the need to handle exceptional behavior. And the object model and use case model are reviewable by the team before anything is committed to code. This review process can catch oodles of errors that otherwise have to be addressed by Constant Refactoring After Programming.

Note that this minimalist style of use case “driven development is not BDUF. It is design for however many scenarios are in the build that you are working on. And it is done at a very similar granularity to stories ”a two-paragraph use case would fit nicely on an index card. It is, however, done within the context of a larger object model, and the use cases are captured in writing, so they are a much more permanent record of what the system has to do than are orally documented stories. The advantages are numerous and include the following:

Unambiguous written understanding of the system behavior.
Behavior requirements reviewed by the team.
Evolution of the object model for all scenarios in the current iteration.
Evolved object model reviewed by the team.
Clean allocation of behavior (functions to classes).
Review of behavior allocation by the team before coding.
No extra work to produce documentation, because use case descriptions, class diagrams, and sequence diagrams are the natural work products.
No big nasty surprises waiting because the exceptional behavior has been overlooked.
Working with an electronic use case model that can be accessed by the entire team helps to develop a shared sense of the big picture ”much more effectively, we suggest, than relying on constantly rotating pair programmers. Heck, people could even gain this understanding while sitting at their nice quiet desk in their own office.

Doing the proper amount of up-front design lets us write code once and only once, and it s entirely feasible for programmers to be successful working alone because it is much easier to write code to an unambiguous behavior spec within the context of a well-defined object model.

Use Cases Are More Rigorous Than Stories

The rigor of anticipating rainy-day scenarios is one of the big differentiators between use cases and user stories. User stories, which can be pretty much anything you decide to write on a card, combined with YAGNI are very weak. Let s explore this in more detail.

In this quote from the C2 Wiki web, Alistair Cockburn describes user stories as 2-bit use cases :

Think of aUser Story as aUse Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit of precision, as they include a model also of the recipient of the message. In the CrystalMethodology family differently founded projects use use cases at different levels of precision. A methodologically light project uses User Stories, a methodologically heavier project uses Use Cases to 4 bits of precision, and Catalysis uses 6 bits of precision. ^[8]

A user story, then, is roughly equivalent to a use case scenario (but without the failure conditions or failure actions ”the rainy-day scenarios). The difference in rigor between use cases and user stories starts with the anticipation of exceptional usage paths in a well-written use case. The processes of story-driven development in XP and use case “driven development are parallel in some ways but have some very significant differences.

We d like to suggest that Alistair s third and fourth bits of precision are incredibly important. What are the failure conditions (really, exceptional usage conditions), and how does the system respond to them? Sunny-day scenarios generally account for less than half of the behavior in any software system. Ignoring the rainy-day scenarios is one of the big factors that makes rapid prototyping rapid, and it also accounts for doing the simplest thing that could possibly work generating a quick illusion of success in XP projects.

Anticipating Failure Modes: Not the Simplest Thing That Could Possibly Work

To a certain degree, acceptance tests help to identify alternative cases by testing as many paths as possible through the system, including errors and failures.

Our feeling is that, although proving useful in other ways, acceptance tests capture the alternative paths in the wrong place. More precisely, the responsibility for catching these errors is shifted from the developers to the customer because writing the acceptance tests is the customer s problem. So, by leaving the problems to be caught during acceptance testing, if a few slip through, that just means the customer wasn t doing his job! XP and the programmers are clean. Also, of course, the alternative paths are caught at the test-driven design stage (aka coding), not before. This is an example of how XP blurs the distinction between requirements and design.

It needs to be obvious to everyone involved that all the alternative paths have been identified. The format typically used for automated tests doesn t really qualify. This is, of course, a matter of debate, depending on whether you feel the acceptance tests (even in supposedly customer-friendly spreadsheet form) are too technical to be classified as documented behavioral requirements.

^[6] Ron Jeffries posting to the C2 Wiki page Extreme Programming, http://c2.com/cgi/wiki?ExtremeProgramming.

^[7] Doug Rosenberg and Kendall Scott, Use Case Driven Object Modeling with UML: A Practical Approach (New York, NY: Addison-Wesley, 1999). Also, Doug Rosenberg and Kendall Scott, Applying Use Case Driven Object Modeling with UML (New York, NY: Addison-Wesley, 2001).

^[8] Alistair Cockburn posting to the C2 Wiki page User Story And Use Case Comparison, http://www.c2.com/cgi/wiki?UserStoryAndUseCaseComparison.