How To Start The Use Case Process For Agile Software Development

racing

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

before the start of the race

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:

partially exposed image

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.

very blurry photo

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.

exposure plus blur

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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

5 thoughts on “How To Start The Use Case Process For Agile Software Development

  1. I have had good results using use cases in two flavors: large projects and small projects. The fast way (small projects) let to the team and users agree on how the system provides functionality to users. It’s important for programmers to know how the user will test the functionality developed and this specification is contained in separate artifact called test case. In agile methods the user story has in the same place both agreement about functionality and how them will be tested. In this perspective is better to have both descriptions in one place.
    I agree with your blog and it has some common concepts with requirement discipline of RUP, and some kind of scope is out in agile methods because they put emphasis on the collaboration.

    1. Thanks, FaustoChi (@faustochi on Twitter), and welcome to Tyner Blain.

      Remember that “agile does not equal lack of scope!” At some level, scope is usually locked, and at the next level of detail it is evolving and collaborative. Just like we make decisions about how to rework our solutions iteratively, we make decisions about how to redirect our efforts iteratively.

      @sehlhorst

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.