Agile Development of Use Cases

We proposed a strategy for developing use cases as part of an agile development methodology last week. In this article, we will look in more detail at that proposal, and also look at a specific way to apply agile techniques to the development of the use cases. What we propose is essentially incremental development of use cases, and starting what comes next as soon as you can.

Why Bother to Write Use Cases?

There are four main reasons to write use cases:

1. Discover requirements that would otherwise go undiscovered.
2. Capture the correct requirements.
3. Communicate the requirements effectively.
4. Prioritize the requirements.

We discussed these goals of writing use cases last summer.

Why Bother With Agile Development?

There are significant benefits to using an incremental delivery process. Agile software development processes vary in the details, but universally include incremental delivery as a key structural component of the process.

Incremental delivery has two primary benefits over waterfall processes:

1. Value is delivered faster by releasing valuable subsets of the product as you go.
2. More value is delivered in total because feedback during the process improves ongoing decisions.

An Agile Approach to Use Cases

Any agile development approach to anything better be aligned with the agile manifesto. In keeping with the spirit of the manifesto, while we are describing a process, we don’t expect (or even ask) that you follow it. The steps in this article are a way not the way to assure a focus on collaboration, interaction, and adapting to change – for the purpose of delivering working software, not the purpose of writing use cases.

If the lists above haven’t convinced you that agile is good, and that use cases are valuable, bookmark this page and come back to it in six months. The arguments may be more compelling to you with more of the experiences that we expect you to have when not doing this stuff.

Getting To Working Software

Keeping the goal of developing working software at the top of our minds, a visualization of a timeline/project plan materializes. Too many late nights with MS Project, I guess.

The Unfortunate Diagram

Unfortunately, some teams think of the comparison between agile and waterfall looking like the following:

Where the only real difference is smaller cycles. Each red diamond represents a milestone or handoff transitioning the focus of the team from one area to the next. The milestone at the end of each arrow represents a release of the software.
For an agile process to get the benefits of agility, the process should look more like the following:

Requirements activity happens first, and at some point, there is enough complete to begin design. After a point, development can begin, etc. It does not mean that the previous activity has stopped. Think about cross-talk between the functional areas:

After design has started, additional work is being done on requirements. Once implementation starts, designs are being refactored, and updates are crossing the “artificial boundaries” between activities. Essentially, you get acceleration by starting each phase as soon as you can, not as soon as the previous phase is complete.

The Use Case Process

Starting as soon as you can is challenging. How do you know when is too early and when is too late? Before answering that question, you should consider the overall process of defining use cases.

You can think of use cases as having a continuum of definition. The use case process should be started after the goals and scope are defined for the project.

The first step of use case development is to define the name of the use case, using the verb-name approach. Some examples would be Open Account, or Create New Order. After defining the use cases (at no more detail than the name), you can define the actors that will interact with the system.

You can define some rough sketches of the use cases as the next level of detail – an intermediate form that is less rigorous than an informal use case. In Patterns for Effective Use Cases, this is called a “brief.” This rough sketch includes two items. First, the actor who performs the use case is identified. Second, a short description of the use case is defined. At this stage, you are not identifying preconditions or post-conditions. The goal is to gain and document a little more detail about the content and intent of each of the previously identified use cases.

You will begin to define the commonalities and dependencies between use cases at this point. Often, you will find that two of your use cases are intended to achieve very similar or identical goals. You will also probably discover other use cases that were overlooked during the initial naming exercise.

One logical next step after sketching out the use cases is to perform a stakeholder analysis. This could also happen after creating informal use cases (free informal use case template) from the sketches. Identifying the stakeholders will help you uncover more details about what must be accomplished by a particular use case – by understanding the expectations that other people have on the actors performing the use cases.

At this point, you can document the use cases informally, or move directly to a formal use case document. An important element of this next stage is to identify the preconditions and post-conditions of the use cases. What must happen before a use case can be executed? And what must happen during the use case to satisfy dependencies on the use case?

You also have an opportunity to refactor your use cases at this stage. Common sets of actions may be best represented as subordinate use cases that are re-used by other use cases. Other refinements and corrections to individual use cases will become apparent as your general level of understanding of the overall project improves.

It can be challenging to take the approach of moving through the stages across the breadth of the identified use cases without going deep to complete individual use cases. Especially when reporting metrics to management. Managers much prefer to see “10 of 30 complete” versus “0 of 30 complete, all are 1/3 complete.”

Start As Soon As You Can

Don’t forget the mantra of starting on the design and implementation as soon as you can. You don’t have to wait until all of the use cases are completed before starting on design. You should wait until at least all of the names are defined.

If you’re taking an XP approach, you may begin implementation with only the use case names (and a rough idea of their potential value) defined. In parallel with this initial development, you should be creating the use case sketches.
You may feel like this is too risky (that you might waste effort on something that will change, or implement lower value items first). If so – define the actors and use case sketches. Then get started. Or wait until you’ve done a more rigorous stakeholder analysis and defined the use cases informally.

If agile processes are new to your organization, you may need to introduce these concepts piece-meal. Perhaps you use the sketches to identify (with more certainty) the more valuable use cases. Then define only those use cases with more rigor, and begin the design work. While increasing the cost of adapting to change and delaying the project (relative to “jumping right in”), this approach may be perceived as less risky to a skeptical management team.

Summary

Use cases are important. Agile processes are valuable. There is a lot you can do with use cases, especially when applying agile principles to improve the quality of your use cases as you develop them. And don’t wait for the use cases to be “done” before moving into design and implementation – pursue them in parallel.

Each team will have a different comfort level, and each management team will have a different level of comfort about moving in parallel. Use your judgement to stretch as far as your team can and overlap development activities with requirements definition. But don’t move too fast – that’s one of the 10 most common mistakes of converting to agile.