The Use Case Blog

User Stories and Use Cases: Not All That Different

Thu, 05 Dec 2013 19:17:00 +0000

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:

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:

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:

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.

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.

Use Cases in an Agile Backlog

Thu, 15 Dec 2011 08:36:00 +0000

A question I’ve been asked a lot lately is, “How do I make use cases work in an agile setting?” I found myself struggling for an answer because a) agile is a mindset not a methodology and b) I didn’t think there was anything about use cases that prevented them from being used in an agile setting. So just do it. But I think the questioners were looking for something more prescriptive. So let’s break it down.

The Backlog

For starters, use cases are a form of requirements, and when we’re being agile, requirements go in the backlog. Often, those requirements take the form of user stories, but they could also be use cases. If they were, how might this work? Consider the composition of the backlog. The items down at the bottom, furthest away from being implemented, are described in a coarse manner. Probably just a name and maybe a description. This feels right since you don’t want to invest much time or energy in requirements long before they will be designed or implemented. That would be the opposite of agile.

So use cases would enter the backlog as a simple name and description. Almost like a placeholder – or an agreement to have a conversation later. This reminds me of the definition of a user story actually. One difference would be, we’d eventually write down parts of that conversation in the form of a use case.

As use cases percolate higher up in the backlog, we’d add more detail to them: a success scenario, some alternate scenarios, maybe related requirements or a wireframe. The risk to avoid here is investing too much effort in detailing use cases that are further down in the backlog. Don’t write documentation you don’t need. The line you want to to be weary of crossing is writing more detail than what is needed to deliver your next iteration.

A Use Case: Too Big for a Sprint?

I think of use cases as one way to group a set of requirements: a user goal, scenarios, constraints, business rules, wireframes, diagrams, etc. As much as I like use cases, one challenge with agile will be, they are too large to be considered an atomic unit of work. By themselves, they don’t make for a useful burn down chart. In fact, you might not fit a complete use case into a single sprint. So the use case – this grouping of requirements – needs to be broken down into some other logical chunks of work.

I’ll cover what those chunks are in my next post.

What do you think? Are use cases and an agile backlog a complete mismatch? Let me know in the comments.

From Goals to Use Cases

Wed, 07 Apr 2010 15:30:00 +0000

Here’s a common scenario for many of us who have learned about uses cases but haven’t written one yet: You’ve identified the actors for your project. You’ve brainstormed a list of goals for each actor. You’re ready to create your first set of use cases. And you feel stuck. Or at least uncertain. Call it use case writer’s block. You could point to a use case if you saw one, but what are your use cases?

When this happens, remember that use cases are based on actor goals. If a use case doesn’t describe how an actor gets something done, it’s not really a use case. Does that mean that every goal becomes use case? Not necessarily. Goals address needs at many levels – from very high levels to very low levels and infinite shades in between. Consider the following goals:

Relax
Plan a vacation
Reserve a room
Find a resort
Pick a destination
Type the name of a city into a text box
Open a web browser

These are all related goals, but at different levels. Not all of them will make for a good use case. Pick a high level goal and the use case will either be too big to comprehend or too imprecise to guide decisions. Pick a low level goal and the use case will be too small and you’ll need too many of them to describe the system. This is starting to sound like a fairy tale involving three bears, but – you guessed it – the best goals are neither too high, nor too low, but just right.

If you’re wondering what goal levels are just right, here’s a more concrete guideline from Craig Larman’s Applying UML and Patterns: Write use cases at the level of the elementary business process (EBP):

A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.

There are exceptions to this guideline, of course. You might want a high-level use case that puts context around the EBP use cases. You might occasionally want a low-level use case that describes a complex sub-process. When you’re identifying the bulk of your use cases, however, most will address goals at the EBP level – something one actor can complete in one place at one time.

To identify the use cases in your system, look at the list of goals you’ve brainstormed. Is each goal written at the elementary business process level? For goals that are written at a level lower than a business event, consider why the actor wants to achieve that goal. It’s probably just a step towards a higher level goal. For goals that are written at a level higher than a business event, consider how the actor would go about achieving that goal. There’s probably an intermediate step that has more business meaning in the system you’re defining.

So, back to our use case writer’s block. You’ve just broken through. Each of the EBP-level goals you identified answers the question: What are your use cases?