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.

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.

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?

Are use cases agile? They’re sometimes regarded as the lumbering, heavyweight cousin of user stories – the requirements technique favored by agile teams.

Use Cases ARE Agile. No… really.

Being agile is an attitude and an approach, while use cases are simply a structure for organizing requirements. There’s nothing about use cases that make them ill-suited for agile teams. Rather, it’s the way that use cases are typically written that is NOT agile (that is, written completely up-front).

So, “Are use cases agile?” is the wrong question. If you want to stay agile, but need something more than a user story, the question to ask is, “How can I write use cases in an agile manner?” Here are four steps to get you started.

Step 1: Start with Actors, Goals, Descriptions

The agile approach favors early feedback and frequent person-to-person communication. Start delivering value right away by holding a kick-off session with the project’s stakeholders. In this session, brainstorm around two questions:

• Who needs to use the thing we’re about to build?
• Why do they need to use it?

To help the discussion, create a context diagram on the whiteboard. You can complete this first session in less than an hour and you’ll walk out with your first set of actors and goals.

From the goals you’ve just identified, create your first set of use cases (some goals will be too broad, some too detailed, some will simply turn into use cases). Name each use case with a verb-noun combination (e.g. Create Account) then write a short description that people will actually read. To avoid getting bogged down while writing the descriptions, you can borrow from a template for writing user stories. Write each description like this:

The [actor name] wants to [goal of use case] so that [reason for wanting to achieve that goal].

Applying this template to the Create Account use case, I’d wind up with something like:

The guest user wants to create an account so that they can access the features available to registered users.

Writing the descriptions might take another hour our two. You can then go back and review the use cases and descriptions with your stakeholders. A few hours invested and already your use cases are adding value – getting everybody aligned with regard to the scope and goals of what you’re going to build.

Step 2: Write On Demand

With a set of actors and use cases in hand, you now have the basic structure around which you can hang as much (or as little) requirements detail as the project requires.

Specifying requirements isn’t a matter of writing stuff down, it’s a process of discovery. Writing too much up-front, adding detail too early will only add to the amount of rework that you’ll be saddled with later. Agile approaches prefer working software over comprehensive documentation. So don’t spend the time required write comprehensive detail to every use case up-front.

Instead, prioritize and decide which use cases will be addressed in the next sprint. Then flesh out those use cases, reviewing your work frequently with the developers who will be implementing them. This will not only preserve your energy, but you’ll learn when it’s okay to stop adding detail to a use case and call it done (hint: it’s when the reader has enough information to move forward).

Step 3: Write Effective Steps

The core of a use case is its main success scenario – six to ten steps that describe how an actor gets something done. When written well, it gives a concise description of how the system needs to behave. When written poorly, it’s a tedious mess that makes the readers’ eyes glaze over. Learning to write succinct, informative steps is the most important skill a use case author can have. It’s also the hardest skill to acquire, since use case steps are so different from the traditional way of phrasing requirements.

Each step should describe an action taken either by the system or by the actor. The actions commonly fall into one of the following categories (if it doesn’t, that’s a clue you might not be getting the step right).

Keep the writing lively by describing the information being passed and the work being done. To keep the scenario readable and maintainable, omit details about:

• the user interface
• the format of the data being passed
• business rules and formulas
• performance (and other non-functional) requirements

Whether you capture these details at all depends on your project’s needs. If you do, the use cases provide a nice framework to hang these other requirements on. Use cases give context and keep readers from getting lost in a sea of requirements. So it’s fine to capture this detail, just leave it out of the use case steps.

Step 4: Adapt the Level of Precision

The reputation use cases have as being non-agile stems from the fact that they are structured in nature (name, description, main success scenario, preconditions, etc). Use cases are typically written with a general-purpose tool (that is, a word processor or spreadsheet). So writers use a template to give their use cases a consistent structure. The problem is, use case templates can lead to some very non-agile behaviors: a box-checker mentality and doing work that just doesn’t matter. There’s nothing agile about filling out forms or writing something just because there’s an empty space in your template. This is what a template compels you to do.

To keep it agile, be flexible about how much precision you capture. Learn when it’s okay to stop writing. Start with the name and description – akin to a user story. If your project can succeed without more, don’t add it. If the stakeholders need more precision, write the main success scenario. Need still more? Write the extensions or add non-functional requirements. Use cases allow you to capture a lot of information, while giving each piece of information the context it needs to remain understandable. But this doesn’t mean you need to capture all that detail unnecessarily.

Yes, Use Cases Can Be Agile

Use cases are just a way to write and organize requirements. While they’re not typically thought of as an agile practice, if you approach them with the right mindset, there’s nothing keeping you from using them in an agile environment.

Because statechart diagrams are visually intuitive, they’re great for capturing business rules in a way that your stakeholders can understand. Statechart diagrams show the valid states that a business entity can take, and the events that make the entity change state.

Suppose you are defining requirements for the order management system of a business that sells customized products. Consider the business rules and workflow for a custom order. The order has to be tracked through the process of taking, planning, fulfilling and delivering it.

To create a statechart diagram (also known as a state diagram or state-transition diagram), think about the different states that an order can take. Each state is a distinct status and is drawn as a rectangle with rounded corners.

Show the valid ways the order can move from one state to another by connecting the states with transitions. The diagram begins with a start state (a filled small circle) and ends with a stop state (a small filled circle within a larger concentric ring). Transitions between states are triggered by events. You can label each transition with the event that caused it to happen. For example, when an order is placed, the order enters the New state (until something else happens).

The statechart diagram will help ensure you and your stakeholders have the same understanding of the business rules. You’ll also discover new business rules by walking through the diagram. For example, can an order be canceled once it is in progress? There’s probably a business rule that determines if and when that can happen.

Consider a business rule that states an in progress order can only be cancelled with a manager’s approval. We can add that to our statechart diagram using a guard condition. Guard conditions are like gates that only open under certain conditions. Use a bit of text to state the condition that has to be true in order to follow a transition (e.g. “Manager Approval”).

As you are developing requirements, you’ll likely discover new states, or realize that other states aren’t valid. Keep your states at a level that is of interest to your business stakeholders. It’s not necessary to capture every possible state – just the ones that are meaningful in the scope of your requirements.

Getting stakeholders to actually read requirements is always a challenge. Put six important paragraphs of requirements next to a diagram and guess what your readers will study. The diagram, of course – everybody likes pictures. Without any training, a business stakeholder can look at a statechart diagram, understand it, and point out where it falls short. This makes the statechart diagram a valuable tool for getting you and your readers on the same page with regard to business rules.

Use cases and templates go together like peanut butter and jelly. No other analysis technique has become so associated with templates. Search the web and you’ll find dozens. Just don’t become a template zombie.

When you find a project team that is focused on producing a standard document rather than on considering the content of that document, then you are in the land of the template zombies.

Adrenaline Junkies and Template Zombies

Benefits and Dangers of Templates

Templates are like checklists. They help ensure you haven’t missed anything. Write something into each field of the template and all your bases are covered. Nothing missed.

The template’s comfortable consistency hides the danger: filling out the template gives a false sense of security. Each project is slightly different, but a template remains the same. We’re fooled into thinking that consistency means quality. When in fact, applying a use case template without thinking introduces its own set of problems. It compels use case writers to:

• Include something that wasn’t needed just to fill in a section, making the requirements more difficult to read.
• Skip an important piece of information because it wasn’t in the template (or throw up their hands and claim that use cases “don’t work”).
• Force traditional declarative requirements into a use case format because they didn’t understand what a use case is.
• Get hung up on form rather than content.

Use cases are not about changing the format of requirements – they are about changing the perspective. Rather than look inside-out (“What are all the the things the system must do?”), we look outside-in (“Who needs to use this system? Why do they need to? How will they use it?”). This results in better requirements that are easier to read, and ultimately, better systems.

The World’s Best Use Case Template

There isn’t one. Being successful with use cases doesn’t mean finding the perfect  template. So stop searching. Don’t be a template zombie. The best use case template is one that you aren’t afraid to change to best fit the situation.

By the time you write your first complete use case, you’ll realize you’re going to have more extensions than use cases. Extensions are the primary way that use cases help us uncover the most important, interesting requirements that we might otherwise miss. So let’s talk about how to write a good use case extension.

First Comes the Main Success Scenario

To understand what an extension is, you must first understand the main success scenario. Of all the parts that make up a use case, the main success scenario is the most central. It describes the interaction between the actor and the system as the actor completes the use case. Here’s a main success scenario for a use case named Create Account:

1. System prompts Unregistered User for new account information:
       Full name
       Username
       Password
       Email address
2. Unregistered User enters new account information.
3. System validates new account information
4. System sends account verification code to Unregistered User’s email
5. System prompts Unregistered User for verification code
6. Unregistered User enters verification code
7. System creates account

It’s called the main success scenario because it describes what happens when everything goes right. Of course, rarely does everything go right, but don’t worry about that just yet. Incidentally, if there is more than one way for a use case to go right, pick the simplest way and make that the main success scenario.

We start with the main success scenario because it’s the shortest path between zero knowledge and understanding what a use case is about. Our readers need this base understanding before they can go any further.

Then Come the Extensions

We still need to describe how the system should respond when things either do not go right or do go right, but not in the way we described in the main success scenario. We call these situations extensions. There are two varieties: exceptions and alternates. Exceptions are failure conditions (something went wrong). Alternates are simply a different way for things to go right. We treat them the same, so I’m not sure why I just bothered to explain the difference.

To create an extension, we need three pieces of information:

• The condition that caused the extension to happen
• The steps that will happen when the above condition is true
• What happens when the steps are complete

The Extension Condition

First, write the condition. Alistair Cockburn identifies two essential traits for the condition: It must be something that the system can detect and it must be something the system will handle. Why? If we don’t limit ourselves to the conditions the system can detect, the possible conditions are endless. And if the system can’t detect a condition, we can’t do anything about it anyhow. So there’s no point in adding it to our requirements.

For example, in step 3 of the Create Account use case, username is already in use and email address is already in use are conditions the system can detect. In fact, since we’d handle both of these conditions in the same way, it will be more effective to collapse them into a single condition: username or email address is already in use.

While conditions like Unregistered User mistyped email address or Unregistered User enters someone else’s email address seem valid at first, it’s not something the system can actually detect (How do we know what the user’s email address is?). Now, if either of these things actually happened, the person who incorrectly received the email might choose to NOT verify the account in step 6. That’s something we can detect, and it’s a condition we’d want to handle.

The Extension Steps and Ending

Next, write the steps that describe what will happen when the condition is true. These are just like any other steps in a use case – they explain the interaction between the actor and the system. For example:

3.a. Username or email address is already in use.

1. System displays an error message
2. The use case continues at step 1

Finally, you might need to write what happens when the extension is complete. I have done this in step 2, above. After the extension, the use case might end, it might pick up right where it left off, or it might continue at another step. If what’s going to happen is obvious, you might choose not to explicitly say so – in the name of simplicity and brevity.

As I said earlier, you’ll quickly find that extensions will outnumber use cases. To find them, consider each step of a use case and brainstorm for the things that could go wrong or vary. Throw out the conditions you can’t detect or handle; combine the conditions that will be handled identically. Then describe how your system should handle them. You’re now prepared to uncover and handle requirements you might have otherwise missed.

People have differing opinions about the role use cases play in the requirements process.

Some people think use cases are just one step in the process – something to start with. Others think that use cases bridge the gap between high-level business needs and functional requirements. Others think that use cases show how functional requirements get realized.

In my view, use cases are the center of the requirements universe.

Of course, I’m not saying use cases are the only kind of requirement. There are other categories:

• Declarative Based. The traditional way to define requirements. These assert conditions that the system must adhere to.
• Model Based. These describe requirements using models that describe behavior (e.g. activity diagram) or structure (e.g. a data dictionary).
• Prototype Based. These describe requirements using a representation of the user interface.
• Testing Based. Test cases are another way to state the observable behavior the system must adhere to.

But at the center of these are the Use Case Based requirements. Each use case is based on a goal of an actor using the system. All other kinds of requirements should relate in some way back to one of those goals. Without the goal, there’s no need for the requirement to exist. So, in essence, use cases really are the center of the requirements universe.

What do you think?

When writing requirements, how much consideration do you give to the reader?

Laura Brandau recently commented that high quality requirements are consumable.

Do you think about who needs to consume your requirements and why? Requirements that are hard to consume are ineffective. A complete and accurate requirements specification that nobody reads might as well be incomplete and inaccurate.

Communication not Documentation

The point of writing requirements down is to communicate - not just document. When creating a design or writing a piece of code, a developer needs to be able to understand which of the requirements are relevant to the task at hand. The same can be said of a quality analyst devising a test scenario or a business stakeholder reviewing your spec. These people, like most of us, can only keep about seven pieces of information in their heads at any given time. If your document fails to communicate what the reader needs to know at the time they need to know it, you've lost.

Use Cases: Consumable Requirements

Use cases go a long way towards making a large body of requirements more consumable. Yes, it's possible to write use cases that are hard to read - I know because I've done it myself. But ultimately, a use case describes how an actor goes about achieving just one goal using your system, and it does it in less than ten steps. The relevant non-behavioral requirements are captured while writing the use case and kept nearby. That way, a reader can understand those requirements in the proper context.

All of this leads to better communication, not just more documentation.

What do you think? Are use cases really more consumable?

I was recently interviewed by Larry Clarkin, co-host of The Thirsty Developer podcast. The interview was dedicated to the topic of use cases (big surpise!). We spent our time answering use case-related questions like:

• What are use cases?
• Why are they different or better than other forms of requirements?
• Are use cases different than user stories?
• What are the downfalls and pitfalls of use cases?
• Do use cases have smells?
• Can there be too many use cases?

It was a lot of fun doing the interview. I hope you'll listen in.

You can download and listen to the show here:

http://shows.thirstydeveloper.com/TD046.mp3