Are Use Cases Becoming Old-Fashioned?

A few weeks ago a discussion popped up on LinkedIn titled “Use Cases are old-fashioned and a waste of time and money“. Provocative, to be sure, the debate that followed (at last count 88 comments and building) was an entertaining romp through the personal biases of a number of experienced practitioners. There were two distinct camps. Arguing against use cases was a group that liked pictures better than words for displaying the sequence of events to fulfill a user goal. For them, taking the time to write use cases is an unnecessary formalism that is too slow to keep pace with the needs of an Agile team. On the other side was more reflective group who viewed use cases as just one more tool in the box for managing requirements, regardless of the the development approach at hand. As a way to get a broader perspective, I thought it might be interesting to see what the Agile Extension to the Business Analysis Body of Knowledge (BABOK-AE) had to say.

For those who haven’t encountered it, the BABOK-AE was developed in collaborative between the IIBA and the Agile Alliance in order to tackle the problem of managing requirements (aka features) in Agile development projects. It was an interesting read, not so much as a way to settle this debate but more as a reminder that good requirements management is just as important in Agile projects as in traditional, plan-driven approaches. What changes with Agile projects is the timing of detailed requirement definition, and an emphasis on face-to-face communication. The real casualty is the comprehensive Requirements Document; use cases are cited along side of other models as simply another lightweight representations of a set of requirements.

So why the debate? Part of it seems to be a concern (obsession?) among Agile practitioners with keeping the design artifacts light. The focus on building functionality that can be delivered within a fixed time cycle demands representations that are just barely good enough to use. It’s easy to see white boards and index cards as are good enough for the moment, and they usually become primary media for recording and communicating requirements as user stories, swim lanes and sequence diagrams. As useful as they are, these representations tend to have a short shelf-life but some Agile practitioners are still suspicious of documents, even thin ones like use cases, as things that transgress a basic tenet of Agile delivery (“working software over comprehensive documentation”).

The word “comprehensive” might be the hang-up. As with any modelling technique it’s easy to get carried away with use case analysis and try to make too many documents with too much information packed into them. But use cases are not supposed to be weighty documents. Authors like Mary and Tom Poppendieck and Alistair Cockburn, one of the original signatories of the Agile Manifesto,  did a pretty good job of showing us how to keep use cases brief. We are not necessarily as good at listening to sound advice that has been around for a while.

Then there’s the the gap between the idealized Agile delivery environment and the reality of many organizations where actual projects take place. When delivery team members are dispersed geographically and dealing with competing priorities, face-to-face communication becomes a luxury and written communication takes on a larger role. Use cases can be useful for grouping user stories together in a way that helps the delivery team see a richer picture that includes triggers, preconditions and success criteria, all of which are part of delivering a customer goal. As well, defining a use case narrative as a main flow with some extensions, alternates, recovery paths and failure modes can help teams break down an epic story that may need several iterations to build completely.

Finally, there just might be some plain shortsightedness on the part of those of us who live in development projects. We forget too easily that developed software ultimately goes into production and will probably be supported by somebody else. The required knowledge transfer is far more than just handing over a stack of index cards at the end of user acceptance testing. Use cases can be a useful starting point for organizing the knowledge base that support teams depend on in order to troubleshoot problems in production when things go wrong.

My own aim is to document just enough information to suit the situation. Use cases are certainly part of my repertoire  but I’m more likely to start with a few user stories and some swim-lane diagrams that set out a high level sequence of events. Sometimes that’s all that is needed; other times, especially when I’m working with off-site developers, documentation will evolve into some “fully dressed” use cases that may include some appendices that serve as a place to gather specification details. Picking the right tool for the job is more a matter of understanding what aids communication in situation at hand than following a set of rules.