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

In the world of use cases, there's this thing called an include relationship. It's an advanced technique that is avoided as often as it is misused - which is to say, a lot. But the include relationship can make you more productive - so it's good to have in your toolkit of use case writing skills.

What Is It?

As the name implies, the include relationship is a relationship that can exist between two use cases. It allows you to insert the behavior from one use case into another. In other words, at some point in Use Case A, you'd jump over to Use Case B, move through those steps, then return back to where you left off in Use Case A.

When Do You Use It?

When writing use cases, you’ll find situations where you have the same exact steps in two or more use cases. For example, in a hotel reservation system, you might find that both the Cancel Reservation use case and the CheckIn Reservation use case need to perform the same steps to find a reservation.

When this happens, you could just write the identical behavior in each use case. Yes, you'd have a bit of redundancy and if the common behavior changes, you'll have to update it in two places. If there are just a few shared steps (say, three or less), then this is the right approach. The cost of creating the include relationship probably won't outweigh the benefits.

If, however, you have more than a few shared steps between two use cases, the redundancy becomes a waste of effort and you'll run the risk of forgetting to keep the duplicate steps synchronized. In this situation, employ the include relationship: Take the steps that are common, move them into their own use case, then include this use case in the place where the steps originally appeared.

Notation and Terms

The use case diagram below shows the UML notation to indicate when one use case includes another. In this example, Find Reservation is the included use case; CheckIn a Reservation and Cancel Reservation are the including use cases.

What's the Downside?

An important benefit of the use case approach is that it makes your requirements easier to comprehend. But the include relationship scatters behavior between multiple use cases - a practice you should avoid as best you can. Requiring your readers to look in more than one place to understand a use case makes the use cases harder to follow. It’s faster and easier to understand a use case if it's all in one place.

In short, the include relationship benefits the author at the expense of the reader. So like any useful technique, it should be applied judiciously.

A Final Pitfall

Do not use the include relationship to simply separate one big use case into a sequence of smaller use cases. If you do, you'll force your readers to look in multiple places just to understand a single use case. This misses the point of making requirements easier to understand. Your use case is just too big. Rethink its scope and rewrite it.

The include relationship is a great technique to have in your toolkit of use case writing skills. Are you using it to remove redundancy from your use cases? Are you encountering any challenges? Tell me about it by leaving a comment here.