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
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!”