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).
| Kind of Step | Example |
| System provides information to the actor | System displays the search results. |
| System prompts the actor | System asks member to accept invitation. |
| System does work on the actor’s behalf | System sends request to payment processor. |
| Actor makes a choice | Member accepts invitation. |
| Actor provides information to the system | Customer enters payment information. |
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.
