Use Cases vs. User Stories: Is There a Difference?
When it comes to use cases vs user stories, I have often been asked, “Are they the same thing?” Short answer: No. The use cases vs user stories debate can cause confusion, but there are some clear differences. One way to think about this is by considering the first word of each name.
Good user stories express a desirable feature of a digital solution from the perspective of a user (e.g., a human or automated system interacting with an existing or proposed digital solution) and answers “What’s in it for me?”
A use case captures a series of interactions between an “actor” (e.g., a human or automated system) and a digital solution to achieve a specified goal. Developers can use a use case to flush out the details of how a user might use the solution to take advantage of a requested feature. It can also serve to provide context for a set of user stories.
To illustrate my point, a user story would be what you need: “As a mother, I need advice regarding how to teach my child forgiveness.” A use case would show HOW you can achieve it. For example, step by step instructions on parenting your child.
Last Updated March 2022
How to Capture, Write, Prioritize, Rightsize, and Flesh Out User Stories including Acceptance Criteria and GWT Tests | By Tom and Angela HathawayExplore Course
A (very brief) history of these complementary concepts
Unfortunately, the long answer is not really as simple as that. (Is it ever?) For history buffs, Ivar Jacobson introduced use cases into the IT vocabulary in 1987, and it became extremely popular for defining how a user interacts with a solution. User stories didn’t come into being in their current context until 1998, when Alistair Cockburn stated, “A user story is a promise for a conversation.”
From a popularity point of view, user stories grew as Agile software development spread. Meanwhile, many (the author included) consider the user story structure to be the best model for expressing what individuals or groups sharing a role need the digital solution to deliver.
The user story paradigm exposed
What has become more or less institutionalized is that user stories (triggers for a conversation) answer the question, “WHO needs WHAT and WHY?” For example:
As a medical doctor (WHO),
I can get a compilation of symptoms (WHAT)
to prescribe the right medication for the patient (WHY).
There is no HOW in a user story
The premise is that implementation of the story is the domain of the developer, not the users, meaning it is the developer’s job to figure out how to deliver the desired functionality to enable the user story to work as the user desires.
A (very brief) user story lifecycle
Organizations that adopt the user story paradigm often begin by defining “epics,” which describe desired business outcomes of a software project at a high level. Once an epic is scheduled for work in a sprint (2-4 week timeframe), it is decomposed into a set of user stories that are at the appropriate level of detail for the Agile technical team.
How detailed user stories are depends entirely on the sophistication and experience of the developers. There is no universal standard regarding a little or a lot of detail. The general rule is a developer should complete a user story in a couple of days of work.
Each individual user story is then evaluated for inclusion in an upcoming sprint or iteration and, if selected, serves as a trigger for a discussion between the developer assigned to deliver the story and the author of the story (by default, the product owner). During the discussion, test scenarios and examples of the expected output are agreed upon.
Top courses in Business Analysis
Acceptance criteria allow the business community to define expected outcomes
To do their jobs, developers need more detail at some point. For that reason, a fully fleshed out user story also provides Conditions of Satisfaction (a.k.a. “Acceptance Criteria”) that specify how the business community will recognize that the user story has been correctly implemented. Those criteria are generally developed by the user community with the help of the product owner/manager and/or business analysts.
Test scenarios validate the implementation of the user story
Test scenarios (often expressed in given-when-then format) take this process one step further. These details are often fleshed out during the conversation that the user story triggers. This occurs between the developer assigned to implement the user story and the author of the user story (possibly supported by a business analyst or product owner). Ideally, the conversation is scheduled at the “last responsible moment” to ensure that developers get the most current information possible when they are ready to start coding.
NOTE: Acceptance criteria and test scenarios exceed the scope of this article, but you can learn all about them in our Udemy course, User Stories: A Collaboration Tool for Business and IT.
Use cases vs. user stories: use cases provide context and address complexity
Use cases are considerably more elaborate. A use case provides a fundamental answer to the HOW question by detailing (at an appropriate level of detail at the right time) one or more potential paths that will lead to an outcome.
Components of a use case description
Each path in a use case depicts the series of events that ultimately lead to a specific outcome (whereas multiple paths can lead to an identical outcome).
A use case also identifies preconditions and postconditions. Preconditions express states and data, which must be met for the use case to work as designed. Postconditions describe states and data that are created if the use case completes successfully.
Example of a business use case
For example, a use case dealing with the user story presented earlier might start as follows:
Use case name: Capture Symptoms
Preconditions: Patient has contacted facility
1. Medical doctor requests patient health record
2. System shows health record
3. Medical doctor interviews patient to identify symptoms
4. Patient describes symptoms
5. Medical doctor adds symptoms to patient health record
6. System prepares physician view of symptoms
Post-conditions: List of patient’s symptoms are available for physician
A01 @ 2 Patient has no health record
A01-01 Medical doctor requests new patient view
A01-02 System shows new patient view
A01-03 Medical doctor captures patient personal data
A01-04 Resume @ 2
Standard, alternate, and exception paths give structure to the use case
There are three types of paths in a use case, which also makes it unique when considering use cases vs. user stories: a standard path (sometimes referred to as the “happy” path), multiple alternate or alternative paths (different ways of achieving the same outcome), and exception paths (what happens when something goes wrong). An exception path does not lead to successful conclusion of the use case, meaning the desired postcondition is not reached.
A use case model visualizes the interactions with actors
A use case model often includes a use case diagram depicting actors and use cases involved in a complex process, as well as a textual depiction of each step in the various paths. Here is an overly simplified example of our chosen scenario:
Use cases provide additional context when needed
Because user stories are specific to the needs of a single role (e.g., website visitor, claims processor, sales agent, etc.), they can be difficult to understand without the context. Many organizations, in particular those that take advantage of offshore developers, have found it advantageous to deliver use case models that show the context for a set of user stories. Each path through the use case has the potential for spawning one or more user stories. It is not uncommon for each step in a path to be expressed as a user story with all the components mentioned above.
NOTE: A detailed explanation of use cases in current software development processes is covered in our Udemy course, Lean / Agile Business Analysis: Writing BUSINESS Use Cases.
Use cases and user stories play well together
Obviously, neither is the much sought-after silver bullet. Taken together, however, use cases and user stories paint a complete picture of a proposed digital solution and allow developers to work with more confidence on what they are expected to deliver. Since use cases define desired post-conditions and user stories provide both acceptance criteria and test scenarios, miscommunication is minimized, avoiding a lot of the problems that plagued agile projects in the past.