What, No Use Cases in the Lean and Scalable Agile Requirements Model?

Just the other day, I received the comments below (read the excerpt below the dashed lines) from Jennifer Fawcett, of www.agileproductpowner.com. Jennifer worked with me at Rational and Proquo (as an extremely capable agile product owner) so we have a long history together.

In her comments, Jennifer asked why there was no mention of use cases in the requirements information model.  Perhaps I haven’t introduced them here yet because:
a) I’ve primarily used use cases myself in the context of RUP-based development, or
b) I’ve seen use cases specifically deprecated in a CSM course. I recently saw a slide that basically said “don’t use use cases, because they are too detailed, exist indefinitely and users don’t understand them”!, or
c) I don’t see use cases applied very frequently in agile teams myself (probably because they are not part of XP and Scrum which are the dominant agile methods), or
d) Given my extensive RUP background, I might have a pro-use case bias. (The book I wrote prior to SSA is entitled Managing Software Requirements: A Use Case Approach.)

However, when building systems of scale, there is no tool quite so powerful as a use case for exploring the interactions amongst users, the systems, and the 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 so often when it comes to system level quality and readiness. (Example: When I’m uploading a big photo from my phone and the battery is low and there is an incoming call, what is the graceful failure path?) This is especially the case when you are building complex hardware and software systems, where system-spanning Epics, Features and Stories bob in and out of hardware and software like a surfacing porpoise.

I’ve been thinking about adding use cases to the requirements information model for some time. In thinking about it, I am also reminded of the fact that use cases have been well applied in other agile models, including: Alistair Cockburn (Writing Effective Use Cases (Agile Software Series)); in the Open Unified Process, the Eclipse Foundation/open source/agile RUP variant, which is even Use-Case Driven; and in the context of the Dynamic System Development Method (DSDM). So I have come to the conclusion that not including them in the agile model was myopic of me and potentially deprived the agile system builder (Ok, well maybe just the reader of my blog…) with guidance towards one of the best available system analysis constructs.

Therefore, I’m going to introduce use cases as an optional element of the agile requirements information model in an upcoming post.

In the meantime, since it was Jennifer’s comments that triggered this reconsideration, and since she took the time to describe the benefits of use cases in agile development and to provide some lightweight agile guidance, I’m including her comments verbatim below: (thanks Jennifer!).


“Hi Dean, I noticed that your meta-model is void of Use Cases! That got me thinking “Hmmm…I’m working in an agile organization as an agile product owner, but I still write Use Cases when I feel the need to! I must be still living my former dark, SDLC (pre agile) life…!”

But, maybe not!

How about exploring how Use Cases can help as a powerful tool in the agile requirements meta-model? Below is some experience I’ve had with agile use cases.

First and foremost, I employ use cases as my primary elaboration technique for the simple agile attitude of constant communication. Our team includes software, firmware, and hardware developers. At our mature stage of the game, all stories inevitably touch all developers, across all disciplines. While we would like to think we all agree, inevitably, we don’t. We are constantly having discussions like: “Should the logic be built into the end device, or the software platform”. “Should the data be pushed or pulled?” “What’s the persistence model, and how long/where should the data persist?” “What are the hardware memory requirements for this story?” Use cases help flush out answers to these questions, and help bring a starting “agreement” among developers as to the initial direction of implementation. That said, we are agile, and it’s all subject to change!

Here’s how we are using use cases in our agile process, and why they work for us.

Why use cases work in our agile process
1. Initial Agreement to Final Agreement
Many Epics or Stories start with a picture or an idea. It’s usually a UI that Product Management has sketched, which defines what the user sees, and infers how the user shall interact with the system. This is often (but not always) accompanied with a story. Defining how the system behaves as a result of the user interaction is the challenge. Use cases provide the perfect forum to analyze and define this initial to final user to system interaction.

2. Statement of Record
Like I said, developers do not always agree (nor do humans for that matter). Use cases provide that simple statement of record for when our brains fail to remember how we thought through the main success scenarios and alternate success scenarios, as well as variations and open issues.

3. Developers Love Them!
A story is not DONE until it’s tested. Most “good” developers write their unit test before they even start laying down code. (some write them after). Use cases give developers a framework for their unit tests before they get going. That’s not the only reason they love them. Developers are often anal (forgive me, I love developers for this reason). Use cases give developers the opportunity to capture details that they feel are important to the story. Careful though…don’t let them get caught in “analysis-paralysis”. As scrummaster, allow discussions, and come to initial agreement honoring the fact that we don’t know what we don’t know, and move on.

4. Business groups gain early understanding
My philosophy is: “Publish everything, and have no secrets.” Our Wiki is golden. By publishing the use cases, all areas of the business gain early access and an understanding of how the system will behave. Stories can provide this same benefit, however, use cases give other parts of your business a “more than they need to know”, aspect, thus covering the proverbial ass and further opening up conversations. Also, this helps get documentation into the agile process early and often.

5. The perfect framework for user acceptance testing
Many conversations happen during the agile development lifecycle. If use cases capture the initial to final agreement per sprint and/or release, what a perfect framework for user acceptance tests (Agile Product Owners LOVE THIS!)

Best Practices for Agile Use Cases
Interview Stakeholders
Before you jot down a word, interview Product Management and the development team leaders. Knowing that the team will most likely not agree, this helps in gaining an initial understanding of what the open issues and what discussion points should take place.

Make them lightweight
No one wants to read use cases that are dozens of pages long. You’ll gain better readership by keeping them short. No longer than two pages should be sufficient to get going. (two may even be too long!). Capture just enough information to get the heads to nod and move on. Make sure you communicate in a language that is common to all stakeholders.

Keep detailed UI design out of it
I struggle with this one, as I am a fond believer in UI detail, but that’s not the goal. Having an exhibit or two with screen shots is fine. Making your use case into a detailed design document is not.

Present/collaborate with your team
Use the daily meet-after opportunity to elaborate and gain feedback. This daily opportunity allows for quick turnaround. Depending on the story, developers often need time to noodle on a use case. Asking them daily until confidence is built helps hedge your bets.

Design them for change.
A simple intro page with a change traceability table will most likely serve you in the future. (post mortems, refactors, etc.)

Write your Use Cases Just-In-Time
After interviewing stakeholders, most Product Owners can kick out a use case in an hour or so. This should happen JIT prior to Iteration Planning. Having a light-weight use case ready at the iteration boundary provides the team a clear framework for tasking and estimating.

All this said, stories are part of our daily agile process too! Not all stories are elaborated with use cases. Some are as clear as a sunny Colorado day. Use cases are brought into the agile process primarily when we want to provide that more detailed analysis of user/system interaction, and gain agreement across the system and developers. I simply employ use cases as another tool in my agile toolbox.

Cheers, and thanks for listening!”

–Jennifer Fawcett


5 thoughts on “What, No Use Cases in the Lean and Scalable Agile Requirements Model?

  1. Hi Dean,

    I’ve read your book and like the way you think about things. I can totally understand why you would want to avoid a discussion of use cases when speaking to an agile audience.

    As we scale agile, it is inevitable that we borrow from those that came before us. There is value in RUP, but unfortunately in many environments, RUP has been misapplied or over applied.

    We can call it iteration 0 and an architectural runway, but what we are really describing here is Inception and Elaboration. We can talk about epics, features, user stories, and tasks; but we are really having a conversation about use case decompostion.

    The sensitivity in the agile community is specifying too much, too early in the process… something I think is rampant and needs to be avoided. On the other hand, documentation is all about communication.

    Do the simplest thing that could possibly work and defer as many decisions (as possible) until just before implementation. If use cases are the best way to communicate the requirements and/or design considerations on a large-scale agile project, so be it.

    Let’s grow up in the agile community and stop demonizing RUP and Use Cases. If those concepts are well applied they can be very helpful to running large scale agile projects. Somewhere along the way, we threw out the baby with the bathwater.

    Thanks for your contribution here.

  2. Great post. I cannot imagine solving any problem (software or otherwise) without mocking up some Use Cases to test my assumptions. First on myself.

    I was doing Rumbaugh at Lexis-Nexis in 1995/6 when UML and Use Cases took over my (development) life. Then I discovered IBM’s VMT and have not done any size project since, without Use Cases.

    Switching to business consulting (circa 2002) has made their application even more profound on my ability to deliver results. Applying them first (and probably the only one ever) to Goldratt’s Theory of Constraints (TOC) and now to Dettmer’s Constraints Management Model (CMM).


    P.S. And yes, Jennifer, the key to me is to “make them lightweight”.

  3. Awesome! It is awesome that we mention use cases here and explore agile development as a goal driven methodology, rather than method driven. Jennifer always sees such things…

    OK, it matters a lot if we “undertake” use cases within agile environment or not, because:
    1) Use case is exactly that sanity level of short term planning that let’s your teams make adequate prognosis and avoid blindness. Absolutely agree with JIT-approach. It makes use cases legitimate;
    2) Who’s said use case is detailed description of what’s gonna be engineered? Not me. I noticed that most efficient use cases are (let’s call them so) “partial use cases”. In every use case the interactions and flows are all of different criticality as well as certainty levels. Important things first!
    3) It reduces entropy because if your team is bigger than 5-7 people, or it is (oh my!) distributed – use use cases and pardon me for this tautology. Instead of sharing their intimate feelings in respect to piece of functionality, they gonna simply synchronize with each other.


    Little bit of off-topic. I noticed there’s a very simple way of determining if you deal with lazy or over-opinionated developer. Dive’em a use case. Lazy will read it, opinionated will not 🙂

  4. I had very interesting conversation on one of my most recent agile club meetings at Luxoft. Somebody from the audience asked about use cases and diagrams and wire-frames and other artifacts and how evil it is to use it in agile team… Guess what I answered. And then there was laud: “Oh no! I heard you telling me earlier that you were almost not using it on one of your projects” – that was another gentlemen who participated in similar event back in 2006 when I was giving my first speech for Luxoft audience. And indeed I mentioned that there’s almost no written documentation and there was reason for that (which was because of very specific project, mostly all based on linguistic and search algorithms along with simplistic UI and trivial user interaction)…

    What is really important and yet sad is that use cases is one of the reliquiae of much bigger and horrific religious battles exactly the same as “whether to write unit tests or not” or “which is better: Windows Media Player or iTunes”. Clear understanding of it gives us a key of how to act in respect to use cases: a) you can’t just introduce them to your team. Instead, it must be a remedy to some chronic disease the team recognizes and b) there must be early adopters that flock around it and gradually involve others by example. Otherwise it’s crusade.

  5. For a lightweight and powerful way to capture use cases, please check out SSNiF Scenarios at http://stealthisidea.com/articles/ssnifs/

    What is special about this technique is that it keeps the cases connected to the user’s underlying scenario.

    This technique can be used both at the detailed level of use cases and at the high level when defining product vision.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s