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

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:

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:

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.

Example detailed use case:

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.

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.