How To Start The Use Case Process For Agile Software Development

One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. [Note: feel free to substitute “user story” or “user scenario” here, if it is more germaine to your process – the idea still applies.] To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?

The Actual Start, Before The Start

The process actually starts with defining goals and scope. In our earlier article, we referenced Suzanne Robertson’s approach to managing scope definition with stakeholders. While her article was targetted at the “you suddenly realize you can’t finish” problem, the same approaches for “defining the scope to begin with” can be used.

Use cases are driven by goals. And the scope of the product or project can be expressed in terms of the goals that it sets out to achieve. For the rest of this article, assume that the goals and scope have been defined.

Just Start Writing Complete Use Cases

Some teams are inclined to just get started. They recognize the catch-22 of prioritizing by value when defining use cases. You have to define the use cases in order to know which ones are the most valuable. Only then can you pick the most valuable ones to define.

Imagine that the “defined scope” is a picture. Doing work on use cases exposes part of the picture to you. The “scope” defines the size of the picture, but tells you nothing about the content of it. Your goal is to implement the most valuable use cases first. With the picture analogy, your goal is to expose the portions of the image most likely to make it distinguishable.

If you just pick a use case, and define it completely, you get to expose a section of the picture perfectly. Unfortunately, you have nothing to guide your initial selection. Metaphorically, you end up with the following:

Any idea what the image is?

Write All of the Use Cases First

Other teams will practice BUFR (big up-front requirements) processes. They can be “assured” that what they work on first will be the most valuable thing. The problem is, they are deferring their agile practice (and its benefits) to the development phase. And arguably, they are defeating a driving principal of incremental delivery – get feedback that refines requirements and prevents wasted effort.

This takes more time, but ultimately you end up with the entire picture before writing any code.

[linked image]

Unfortunately, after investing a lot of effort, there is nothing to deliver (except documentation) – and the goal is to deliver software. Besides, by the time you start delivering against the completed (and expensive) use cases, you may find that the customer actually wanted [another image]. At least with the “just pick something” approach, you will quickly find out that your requirements were wrong, and fix them.

There is a better way.

Breadth First Use Case Definition

You can take an iterative approach to developing use cases that is neither of the previous examples. You can define the entire scope of use cases (like BUFR), but at a very low level of detail (not like BUFR). And you can do that faster than you can define the initial use cases.

Start by defining the use case names. Then define very rough outlines that describe essentially what the use cases represent. This level of detail provides guidance and some insight into the relative value of the use cases. In keeping with our picture-discovery theme, this would be the equivalent of a complete, but extremely blurry view of the product scope.

While this still represents incomplete information, the breadth of information allows you to make much better decisions about which use cases to define first. Your first iteration, instead of completely defining four use cases (or four sections of the photo) may be made up of only two use cases plus the set of use case names. The chances that you’ll implement valuable use cases are much higher.

Some of you may still not know what the image represents, but many more of you will. [link to full image]

Summary

Breadth first, then depth. Use case names (and rough outlines or descriptions) can be quickly defined, and coarsely valued. The most valuable ones can be selected for implementation first. This is the key to defining use cases (or scenarios or stories) in an agile software development project.

We believe this is one of the cornerstones of developing an agile requirements process.