Use Cases in the Agile Enterprise Requirements Information Model

Note: this is the conclusion (for the moment at least) of an extended series on a Lean and Scalable Agile Enterprise Requirements Information Model, which can be found in the Agile Requirements blog category.

In an earlier post “What, No Use Cases in the Requirement Information Model?”, I noted the following.

“Regarding use cases, I haven’t yet made them citizens in the agile requirements meta-model. However, when building systems of scale, there is no tool quite as powerful as a use case for exploring the interactions amongst users (and other actors), the system, and subsystems of the solution. Moreover, the use-case technique is the best way I know to help identify all the alternate scenarios that trip us when it comes to system level quality and readiness…I am also reminded of the fact that use cases have been well applied in other agile models ……. ( see post.) so I came to the conclusion that not including them in the agile model was myopic of me. Therefore, I’m going to introduce use cases as an optional element of the agile requirements information model in an upcoming post.”

This is that post.

Benefits of Use Cases in Agile Development

While use cases are not a replacement for the user story in agile development, they can be of tremendous benefit in elaborating, analyzing and better understanding the intended behavior of complex systems. For example in a prior post, Jennifer Fawcett (agileproductowner.com) described benefits of use cases in the context of agile development, highlighting : ( my paraphrasing)

“use cases are a statement of understanding whereby developers can first agree, and then remember, (how it was that this complex system was supposed to work), including main success scenarios and alternate success scenarios, as well as variations and open issues.”

Use Case Basics

use-case-model-graphicFor anyone not familiar with use cases, there are dozens of good books on the topic, including Cockburn’s Writing Effective Use Cases (currently the top ranked book I could find on Amazon with agile and use cases) and Leffingwell and Widrig’s Managing Software Requirements: A Use Case Approach .

But for the uninitiated, I offer the following summary:

A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor.

Where:

  • Sequences of actions —describes a set of steps; i.e. functions performed by the system that produce a result.
  • System performs—the system works on behalf of the actor. It does what it does when the actor (or other system or device) tells it to.
  • An observable result of value—the result of this activity is some benefit to the actor. (Otherwise, why bother?)
  • A particular actor—someone (user) or something (system or device) that interacts with the system

Use cases also have a well defined canonical form, which is broader, deeper and allows for a more complex description of the systems interactions that does the user story (see my user story description in this post). The standard use case form appears below:

The description is a short summary of the use case (not unlike the “Card” part of the user story). The flow of events is the pithy part and it itemizes the series of actions between the actor and the system. Pre- and post-conditions provide state information that is relevant at the time the use case is executed. (Example: “the URL data server has to be initialized before this use case is executed”) that further describe the expected behavior of the system under those conditions.

It is the alternate flows (or alternate scenarios) that provide much of value to the agile system builder. For it is here where we are forced to think through all the “what ifs” that might affect our user story. For example: “what happens if the URL server is initialized, but it returns a null result” or ” if my phone battery is low—and I’m uploading a big picture —and an incoming call comes in—what happens then?” Understanding all the alternate flows of a use case fleshes out the various (usually less likely) scenarios that the system must handle with grace in order to assure system level reliability and quality.


Use Cases, User Stories and Incremental Development

As we’ve indicated, use cases are not a substitute for user stories and you don’t have to use them at all. However, if your system is complex and is composed of subsystems (what complex system isn’t?) then use cases provide a mechanism to help force the developers into thinking about all the possible paths through the system that the users may encounter as well as the various states (pre- and post-conditions) that must be addressed.

In turn, this helps the team understand where user stories of various types are likely to be needed. These appear as “story pockets” in the figure below:

Use Cases Traversing a System of Systems

Use Cases Traversing a System of Systems

In addition, once understood, the use cases themselves can drive agile and incremental development, one story at a time, as Per Kroll’s graphic below illustrates.

Sequencing User Stories in Iterations

Sequencing User Stories in Iterations

In this graphic, one can see how user stories get implemented in bite sized (iteration sized) chunks over time (story 1 – iteration 1, story 2&3-iteration 2, etc). To the agile developer or product owner, this can be extremely helpful in understanding the larger system picture that can be easily lost when the teams focus on “one user story at a time.”

Use Cases in the Information Model

I apologize if I’ve belabored use case basics too long. But here’s what we’ve learned.

  1. Use cases are optional but can add tremendous value to understanding behavior when the system is complex
  2. Use cases help teams understand all the “what if” scenarios that ultimately affect system quality
  3. Use cases can be used to understand where new stories are likely to be found
    and,
  4. Use cases can provide a logical way to sequence value delivery in big systems, story by story

In other words, use cases are an optional technique which we can use to better elaborate desired system behaviors.

In our agile requirements model, system behavior is expressed as Backlog Items, so let’s put use cases there, on the advanced form of our agile requirements information model, like this:

capture-use-case-highlihts

Summary and Use Case Tips

In this post, we’ve elevated use cases to become first class citizens of the agile enterprise requirements information model. They are a tool, like all tools, that work best in certain situations. In the case of use cases, they work best when the system is complex, and is composed of subsystems and components that must cooperate to deliver the larger value for the user.

If you decide to use them, keep these tips in mind.

  • Keep them lightweight- no design details, GUI specs, etc.
  • Don’t treat them like fixed requirements. Like user stories, they are merely statements of intent
  • Don’t worry about maintaining them, they are primarily thinking tools
  • Model informally –whiteboards, lightweight use case diagrams etc. –but code formally with your disciplined XP-like programming practices.

As an agilist, remember you don’t have to use them, but no one can tell you not to use them either and you’ll likely be quite happy if you do!

About these ads

2 thoughts on “Use Cases in the Agile Enterprise Requirements Information Model

  1. Use cases are also good for breaking down stories into tasks. The actual need for breakdown usually appears after team painted flows on the whiteboard. I would say these three things often come together: Story breakdown, Story estimation and Drawing use case.

  2. Good post / series. While a use case can easily be associated with a story, I personally think it’s a better fit at the feature level. A good use case will provide clarity throughout the system in a silver thread manner.

    It’s always best to focus on end to end implementations in order to ensure you are truly delivering what matters. Aside from delivering more value to the Product Owner and end customer, you also increase the knowledge of the team and in the process teach them to deliver more business value in general.

    Use cases can often live even longer than that. You may be able to augment a previous use case with one or two new paths / scenarios to implement an additional epic in a subsequent release.

    Finally it also helps clarify the difference between acceptance criteria and use cases. The story more often than not likely only addresses an aspect of the use case. Granted, I am making the assumption that user stories are very granular and in terms of size, never more than 2-3 days (MAX). Anything larger and you start to wonder if the team can get their stories done, done, done within the iteration.

    Mo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s