Use cases: a personal history (and a bit of a love affair)

I recently discovered that even after 200 blog posts here, I’ve never written about a post about my beloved use cases! I guess I think that most of what there is to say has already been said. But we’ve each got our own story about how we discovered use cases, what we do with them, and how they help or hinder us. Here’s mine.

I’ve used use cases in different ways throughout projects over the last 7 years.

In my early days as a business systems analyst in a relatively-RUP process, the use cases were the center of our world. After “baselining” a hefty 50-60 page requirements document, we’d dive into use cases. We’d hold reviews with the business stakeholders, development team, project managers, and QA and painstakingly review the details of the use case alongside the user interface wireframes. Many of these discussions were essentially design discussions as we all struggled together to figure out what, how, and what’s possible all at the same time.

I’ve come to realize that these meetings were woefully inefficient and violated the basic tenet of separating “what” and “how”, but man were they fun! We had a great time debating details, discussing options, and finding solutions. At the end of the process, we all had a fairly good shared understanding of what was to be done. Then deadlines, quality issues and integration surprises would unvaryingly compromise the beautiful use cases we’d all agree to. The requirements and design process was so much more elegant than the realities of implementation. I’m exaggerating a little here; I’ve already admitted I’m a perfectionist.

Despite the unhappy endings, I staid the course through my next two positions. First as a solo BA in a small start-up and next as a BA manager at a larger “reborn” start-up where we were merging the IT systems of 5 real start-ups into one. Truth be told, I didn’t really know any other way to be a business analyst. Focus on the use case I kept saying and eventually we will figure this whole implementation thing out.

You really can’t blame me. Use cases have a sort of internal beauty. They just so perfectly get you from point A to point B. The very act of writing a use case inspires some of my best systems thinking. The act of reviewing and validating a use case can create active discussions about the actual requirements.

But looking back, I’ve never seen them used as the cornerstone of a widely successful project implementation. There is something missing in the process, whether its a design document, that horrid-looking 20-page template for a “use case realization” deliverable we used to throw at scoffing developers, or simply a smaller way to break up functional requirements. Even with the level of detail I typically include in a use case (which I’m learning is wildly atypical and worthy of a separate post) there needs to be something between the use case and the implementation or there is a lot of pain and requirements change as things really get sorted out.

Then I come along to my first agile project. It becomes agile after I start it as RUP (because that’s what I know and that’s what the client had used before). So I’ve got a use case list and it needs to become a user story list. User stories are smaller, more granular, and development driven.  After a month or so fighting through this transition,  it clicks. User stories, done well, could solve the implementation problems. They elevate all kinds of details that use cases brush under the rug. They force me to prioritize that new alternate flow that “just has to be there” instead of embedding it into a use case and hoping it makes it’s way into a design document or project plan. All good. All good.

In this project, I also have the opportunity to document some business process changes. And where do I start? Of course, with my beloved use cases.

Then I land a client with even less process, more desire for quick results, and small development team than anywhere I’ve worked before. At first they just want wireframes because they find them easy to develop from. This works for phase 1 because it’s a fairly simple project, but phase 2 is heavy on functionality and interactivity. I can smell it…we need some use cases. I start with using use cases simply to analyze the problem, never showing them to anyone. I fully realize now how much I love them because of the good thinking that comes from them. You simply do not think this well staring at a set of wireframes. The rules don’t elevate themselves, the analysis just doesn’t happen.

But then I start to struggle in the wireframe reviews. The developers need the use cases too. They don’t want them, but they need them. Wary of “too much documentation” phobia I try something different. I throw out my templates with headings, and document information tables, and numbers like section 3.1.1.2. I start with a blank Word document. I write a description. I create a flow of events with basic 1, 2, 3 numbers. I add in alternate flows and exception flows, again 1, 2, 3. I add a bullet list at the end to capture open questions and key discussion points. I’ve captured the absolute essence of a use case in its most simple form. Most use cases fit on a page.  In the end, these use cases passed the muster of a simple document for a team that didn’t want too much documentation.

And here I am on my next project. Again responsible for building a requirements process, but not too much of one at first as we begin to integrate the BA role into the development process. Again figuring out how to bring multiple new stakeholders into an agile environment. Again using use cases upfront to analyze the problem and knowing I’ll need them again on the back-end to document the system. And again trying to find if they have a place in between or if user stories will fill the bill.

I’ve had a long history with these things we call use cases. One might even call it a love affair of sorts. It’s always nice to find a tool that makes you better at what you do. I think no matter what I do, use cases and use case thinking will have a home in my mind and a bit in my heart.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Friday Flip: Alistair Cockburn quote about user stories and use cases
2. Technical specifications and system documentation can take different forms
3. Help a BA!: What is the difference between a business analyst and a systems analyst?