User Stories and Use Cases: Not All That Different

TL;DR In the beginning, user stories and use cases are nearly indistinguishable. In the end, they serve distinct purposes and could look very different. Who cares? Anyone who wants to deliver projects in an agile way but still have a written record of what was built when it's done.

They Start Out the Same

I know this is well traveled territory and the consensus on the internet is that user stories and use cases are so different that to suggest any likeness between the two would be absurd. But before you lecture me about gazelles and gazebos, I humbly submit:

User Story vs Use Case

I know what some of you are thinking, "Wait wait... user stories are lovingly written on index cards crafted from post-consumer content while use cases destroy countless trees each year to build the weighty tomes in which they live!" To you, I humbly submit a use case:

Use Case Index Card

Sometimes, this is as far as I’ll take a use case. If I write my use case on an index card or sticky note, does it become a user story? The truth is, the amount of detail put into a use case is entirely up to you. You're free to add more detail than is useful or necessary but, of course, you would be doing it wrong.

Let's look at a few definitions from respected authorities in this area:

User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

Mike Cohn - User story expert

I like this.  I like short and simple. I like writing from the perspective of a user. Am I allowed to write a short and simple use case? Or would that make it a user story? And here:

A use case is all the ways of using a system to achieve a particular goal for a particular user.

Ivar Jacobson - Inventor of use cases

So you could say I'm wrong and that user stories and use cases are beyond comparison. And I could say, “Gosh, I certainly do see some similarities between the two.” For the record, I understand the nuance that the intent of a user story is away from documentation and the intent of a use case is often to write things down.

Why Do We Care?

So why do I want to have this debate? Actually, I don't. I'm not a methodologist. I would rather get my hands dirty building something than have a debate over semantics. If you love user stories and don't care for use cases, then write your stories, agree to have a conversation about them, and be happy. But here's the problem I'm trying to solve: there are a growing number of teams who want to achieve two objectives:

  • They want to deliver a project with the agility afforded by user stories. They want to add value sooner and in smaller increments, whether doing sprints or continuous delivery.
  • Once their system is delivering value, they want to have a more detailed, written record of how parts of it are supposed to behave and they've found that use cases are at least one component of that record.

We find these teams in regulated industries like finance, manufacturing, and biotech, as well as other places like the public sector.

If we want to be agile but also want use cases, we can't deliver them whole. They're too large to qualify as backlog items. We need to divide them into bite sized pieces that can be delivered incrementally. How do we do that? Well, there are two ways to break down a use case: a) into scenarios or b) into smaller use cases.

Use Cases to Scenarios

A use case is a combination of its main success scenario plus extensions. The main success scenario is the simplest or most common path that achieves the use case goal. The extensions cover all the other ways the use case could succeed or fail. Visually, these combinations would look something like this:

Use Case Scenarios

Each scenario could be delivered independently. This works because a scenario is obviously smaller than the entire use case and, in fact, there's good reason to deliver use cases this way. Add value early by shipping just the simplest or most vital scenario first. Then, deliver extension cases later. The most obscure extensions might not be delivered at all, but instead get handled manually outside of the system (an idea I first heard from Jake Calabrese).

Here's the rub: these scenarios are not user stories. If you're bent on delivering user stories, this approach isn't for you. Why? Because the goal of each scenario remains the same regardless of the path the user took to achieve it. If you tried to write a user story for each alternate path (an extension that succeeds), they would all look the same. And, as far as I know, there is no such thing as a user story for an exception (an extension that fails).

Although each extension isn't its own story, the relationship between a use case and its extensions resembles the relationship between a user story and its conditions of satisfaction, - a set of criteria that gauges whether the story was successful.

Use Cases to Smaller Use Cases

Before I dive in here, understand that it's entirely possible that a use case might be small enough in scope to deliver on its own, as-is, in a single iteration. But if the use case goal is too lofty to deliver in one agile swoop, we could just break it down into smaller use cases where each sub-use case is focused around an incremental goal - a step towards the overall goal of the parent use case. This sounds a lot like an Epic, a large user story that gets broken down into smaller user stories so they can be delivered incrementally.

Dividing Use Cases

This is where use cases and user stories really start to smell the same to me. I can break an epic user story down into smaller user stories until the stories are small enough to deliver in an iteration. I can break a large use case down into smaller use cases until the use cases are small enough to deliver in an iteration.

As use cases become smaller in scope, we can vary the amount of detail we add to each one. I might write step-by-step scenarios for some, but for others I might write only a brief description. To some I might add a wireframe or workflow diagram. For others, I might write acceptance tests only. At this point, the line blurs between use case and user story. A use case with only a name and description looks a lot like a user story. But with this approach, you'll have organized your requirements into pieces small enough to deliver incrementally without losing the big picture view that comes from having a larger use case model.

To wrap up, I'm not advocating use cases over user stories nor am I advocating the opposite. My point is, if you want use cases, you can have them and you can still deliver value incrementally, the way you might with stories.