Check out our latest free video – 4 steps to incredible story maps Watch now

Use Cases vs User Stories. What Are The Differences?

Anthony Murphy Anthony Murphy
9 minute read
Use Cases vs User Stories. Let's learn about the differences.

A common question that comes up is the difference between User Stories and Use Cases. Whilst being different things they share many similarities.

In this article we’re going to take a look at user stories and use cases, what each of them are, what their similarities are, differences and when you should use one as opposed to the other.

Quick compare — user stories vs use cases

User storiesUse cases
Mid to high level of detailLow level of detail
Uses everyday languageUses technical and business language
Easy to useHarder to use
Describes the user's behaviorDescribes the interactions between the actor and different systems
Facilitates communication and collaborationIs the primary communication tool
Solution agnosticDefined solution

What is a user story?

User stories are a common agile tool that originate back to the 90s with Ken Beck and XP (Extreme Programming). In 1999 Kent Beck published the first version of his book, ‘Extreme Programming Explained, introducing Extreme Programming (XP)’ where he introduced the framework XP to the world, along with the first formal appearance of the term user stories.

Ron Jefferies, another Agile Manifesto signatory, took the term user stories and proposed the framework known as the 3 C’s. The notion being that a user story at its core are;

  • The Card (or often a post-it note) is a tangible physical token to hold the concepts;
  • The Conversation is between the stakeholders (customers, users, developers, testers, etc.). It is verbal and often supplemented by documentation;
  • The Confirmation ensures that the objectives of the conversation have been reached.

Since then user stories have grown in popularity and are the most commonly adopted way for agile teams to articulate their backlog items.

In the book User Story Mapping by Jeff Patton, Patton recounts Kent Beck’s thinking like this:

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does:

"I type in the zip code and it automatically fills in the city and state without me having to touch a button!"

I think that was the example that triggered the idea. If you can tell stories about what the software does and generate energy and interest and a vision in your listener's mind, then why not tell stories before the software does it?

The idea being that backlog items can be written from a user’s perspective — as a story. Ideally one that articulates who they are, what they’re trying to achieve and why. A user story is then a card that contains this information, helps to facilitate a conversation about it and then contain a way to confirm that the user story has been completed.

User story narrative

A common format for articulating user stories is known as the user story narrative.

This format was created by Rachel Davis and her colleagues at the company Connextra. The user story narrative follows the following format:

As a <role>
I want <capability>
so that <receive benefit>

This covers who this user story is about, what they want to achieve and crucially why they want to achieve it.

Since then many others have adapted this narrative to suit their needs. For example, putting the ‘why’ first:

In order to <receive benefit> as a <role>, I can <goal/desire>

As well as covering the the 5 Ws:

As <who> <when> <where>, I want <what> because <why>

And many more.

However regardless of which user story narrative you use or not, remember that a user story at its core is a card, a placeholder for a conversation and confirmation.

User story narrative example:

Handle returns

As a buyer (shopper who purchased a product)
I want to return items that I no longer want
In order to get a refund for the undesired items

Acceptance criteria

The last C in the 3 C’s for user stories is ‘confirmation’. The most common framework used to confirm a user story has been completed is acceptance criteria.

Mike Cohn defines acceptance criteria as “notes about what the story must do in order for the product owner to accept it as complete."

Acceptance criteria typically contain both functional and non-functional requirements that need to be satisfied in order for the story to be complete. Also sometimes referred to as ‘conditions of satisfaction’.

There are many ways to write acceptance criteria but the most common is a simple bullet point list.

Acceptance criteria should be written in a way that it’s clear, specific, unambiguous and testable.

This is important as acceptance criteria is our way of confirming if the user story has been completed. If it is unclear or untestable then there is no way to confirm that we have met the conditions of the user story.

User story with acceptance criteria example:

Handle returns:

As a buyer (shopper who purchased a product)
I want to return items that I no longer want
In order to get a refund for the undesired items

Acceptance Criteria:

  • Only returnable items can be refunded
  • Verify the returned item was purchased within the last 30 days
  • Confirm that the returned item has a valid receipt that states:
    • Receipt ID
    • Purchase date (within the last 30 days)
    • Price
    • Payment method
  • Verify that the returned item complies with refund policy
  • Returned item is still has the tags attached
  • Verify that the returned item has not been damaged
  • Refund the shopper the exact amount paid on the receipt for the valid returned item via their original payment method

Understanding user stories is one thing, but writing them into a usable backlog and plan of action is quite another. It’s pretty common to use a user story mapping tool like Avion to both plan and author your user stories. But, you can also start off using tools like Jira or even Google Sheets, if you’re budget is tight.

What is a use case?

A use case is a technique predominately adopted in software engineering to articulate the interactions between users (often referred to as actors) and systems.

Use cases predate user stories and have long been a dominant tool when it comes to requirements documentation, system analysis and software testing.

Use cases were first introduced by Ivar Jacobson Swedish computer scientist and software engineer. Originally called usage cases, a direct translation from the swedish term, användningsfall, the term didn’t translate well to english and was later coined as use cases.

Through describing user actions and how we expect the system to respond to them, use cases present a more user centric and scenario based approach to requirements and software development.

Consider buying an item online. You will have a user, the actor who arrives at your online store and searches for an item, as they do so the website will need to communicate to the backend, as well as external systems, like payment gateways, etc to fulfill their order. A use case aims to walk through a single scenario (say purchasing a shirt) and describe how the actor and the systems will interact.

Like user stories, there is no single way to write a use case. There are many different templates and formats popularized over the years.

However fundamentally a use case typically covers these 5 areas:

  • Goal: The goal of the actor in the use case
  • (Primary) Actor: Who is the actor in the use case and whether they are a user or another system?
  • Preconditions: What is the state of the systems at the start of the use case?
  • Steps: The series of steps the actor and systems will take in the use case
  • Alternative paths: What alternatives paths might the system take within the use case?
  • Post-conditions: What is the state of the systems at the end of the use case?

To give a detailed example of a use case template, the following one of the most widely adopted formats from the book — Writing Effective Use Cases, by Alistair Cockburn.

Writing effective use cases by Alistair Cockburn
Use case title"an active-verb goal phrase that names the goal of the primary actor"
Primary actorWho is the primary user or system in this use case?
Goal in contextA longer statement of the goal, if needed
ScopeWhat system is being considered in this use case?
LevelOne of:

  • Very High Summary
  • Summary
  • User Goal
  • Subfunction
  • Too low
PreconditionWhat we expect is already the state of the world
Success end conditionThe state of the world we expect upon successful completion
Failed end conditionThe state of the world we expect if goal is abandoned
TriggerThe action upon the system that starts the use case
Main success scenarioThe steps of the scenario from trigger to goal delivery, and any cleanup after
ExtensionsAny extensions to steps in the main scenario
Sub-variationsAny sub-variations that will cause eventual bifurcation in the scenario
PriorityHow critical is this use case to your system or organization?
StakeholdersInterested parties in this use case
Performance targetThe amount of time this use case should take
Secondary actorsList of other users or systems needed to accomplish the use case
Open issuesList of open issues about this use case
ScheduleDue date or other schedule and staffing information you need

Example detailed use case:

Use case titleReturn unwanted item
Primary actorBuyer (shopper who purchased a product)
Goal in contextA recent buyer who purchased an item has requested to return their unwanted goods.
ScopeShop
LevelSummary
PreconditionThe buyer has the item they wish to return and a valid receipt
Success end conditionBuyer is refunded for the good returned for the amount specified on the receipt via their original payment method
Failed end conditionBuyer is unable to return goods
TriggerBuyer returns to store and request refund
Main success scenario
  • 1 – Buyer who recently purchased an item no longer wants it
  • 2 – Buyer returns to store
  • 3 – Buyer request refund
  • 4 – Shopfront staff validate the item was purchased within the last 30 days
  • 5 – Shopfront staff verifies the item still has the tags attached
  • 6 – Shopfront staff verifies the item is undamaged and unused
  • 7 – Shopfront staff processes refund for the amount paid on the receipt to the original payment method
Extensions
  • 3a – Buyer requests an exchange for the item
  • 3a1 – Shopfront staff verifies the exchanged item is in stock
  • 7a – Shopfront staff take returned item
  • 7a1 – Shopfront staff process new receipt for exchanged item
  • 7a2 – Buyer receives exchanged item
Sub-variationsBuyer may request refund online, by phone

Buyer may request exchange for an item of greater or lower value
PriorityHow critical is this use case to your system or organizationHigh
StakeholdersStore Manager, General Manager, Supplier
Performance target10 minutes until refunded
Secondary actorsStore Manager, Supplier, Payment Gateway
Open issues
  • What happens if the requested item for exchange is not in stock?
  • What if we cannot process refund via their original payment method?
ScheduleQ3

Use case diagrams

Another variation on use cases is to visualize them. This is known as use case diagrams.

Use case diagrams may represent one or more use cases in a single diagram. Since they are graphical in nature it’s common for them to represent multiple use cases and how multiple actors and systems interact with each other.

This makes use case diagrams less detailed than use cases as they wont be able to drill down into the multiple edge cases and details however they provide a valuable tool for communicating to stakeholders about how actors interact with the system.

Example use case diagram
Example use case diagram

To sum up, what are the differences between a use case and a user story?

Whilst user stories and use cases were both designed to describe the expected system behavior from a user’s perspective they are two very different tools. And whilst they do share similarities they have far more differences.

Alistair Cockburn describes the differences as:

A user story is synonymous with “feature” as used in the 1990s, a marker for what is to be built, fine-grained enough to fit into modern iteration/sprint periods. A use case provides a contextual view of what is to be built, serving to bind the organization together, among other things.

User stories and use cases aren’t mutually exclusive. They’re simply optimizing for different things. User stories seek to optimize for collaboration, after all, at their core they are the 3 C’s (Card, Conversation and Confirmation). Therefore user stories are typically written in everyday language and have less detail because they’re more focused on facilitating a conversation within the team about what needs to be built.

On the other hand, use cases optimize for detail and reduce ambiguity. As a result they are often written in more technical language and serve as the primary tool for communication. Someone can pick up a use case, read it and understand in detail what the system needs to do and how different pieces fit together.

Therefore they both still serve a purpose in product development. Using user stories doesn’t prevent you from using use cases - or visa versa.

In fact, some find it beneficial to have both since they operate at different levels of detail. As Cockburn said you still need the user story to describe the ‘feature’ level of detail, whilst also needing the use case level to provide the detailed and contextual view of the solution design of what is going to be built.

Anthony Murphy

Anthony Murphy

Hey 👋 I'm Anthony, people call me Ant. I'm a seasoned product leader turned Product Coach. I'm passionate about helping product people and companies do product better. A prolific writer and speaker, I aim to share as much of my experience as possible. I'm a Director at the Association of Product Professionals and Founder at Product Pathways. I love a good coffee, craft beer and, am a father to two cats and a little human.

Continue reading

  • What does a product manager actually do?

    What does a product manager actually do?

    Product managers are creators. They’re problem solvers. They facilitate solutions that people value.
    Read more
  • Lean Agile – Bringing Them Together To 5x Your Delivery

    Lean Agile – Bringing Them Together To 5x Your Delivery

    Lean and agile have a lot of similarities. They both focus on rapid, iterative development in order to deliver value to customers faster and avoid wasted development time by producing unnecessary features.
    Read more
  • A Simple Guide To The Product Discovery Process (with Examples)

    A Simple Guide To The Product Discovery Process (with Examples)

    Product discovery helps product teams uncover customer problems and validate solutions — let's learn how to create an effective product discovery process.
    Read more