Can one use use cases on a agile project? do use cases provide any value for agile teams?
I' m going to put out my opinion unequivocally Yes, Yes and Yes.
Most agile purists would disagree with me on all the three above points. Typically agile development approaches use user stories, backlog items, or other simpler mechanisms to describe requirements. They often have the format of "as a student i can purchase books". These requirements are typically put on an index card, and then not elaborated until it's time to code, and usually only by conversation, sometimes with a couple lines of text.
First of all let me state that I find user stories very useful for estimating , planning and tracking. I don't however find them very useful for providing context, structure, or abstraction. My experience has been that using user stories alone does not scale very well when working on large projects where multiple views of requirements are needed. For instance, a high-level view for project directors and other executives or a more detailed view for developers.
I can appreciate the bias that most agile practitioners have against use cases, because frankly, most use cases that I have come across in my experience are very poorly done. They are hard to read, they have way too much structure, rely way too much on UML syntax (extensions and usage relationships) and can often digress into what I call "functional decomposition". In order for use cases to provide value to any Project, agile or not, they need to be written properly. I specifically recommend two excellent books, Patterns for Effective Use Cases and Writing Effective Use Cases both of which Alastair Cockburn either authored or co-authored.
What I have euphemistically coined the "Cockburn Use Case Approach" describes how to write use cases with just enough formality and structure to allow proper abstracting, good context, multiple views, etc.; while still being readable by end-users, and not requiring a massive amount of effort to build and maintain. Most importantly, this technique focuses on writing scenarios using natural text, not on creating uber complex UML diagrams.
Alistair Cockburn has posted a pretty good piece justifying his use of use cases which I recommend taking a look at.
Some other comments on the topic can also be found here
A Brief Case Study
I have decided to share a brief case study regarding the own experience with user stories and use cases in general.
About five years ago I was asked to take a fairly large public sector program that was being previously conducted in a waterfall fashion and focus on getting some very quick functionality out the door. The client was previously frustrated by the millions of dollars spent with only paper documentation (and not very good documentation at that) to show for it. I lead a small task force of around five developers for about six months, our goal was to try to win back client confidence by delivering "something" quickly, and iteratively. We followed the XP process as it existed at the time, using user stories, velocity, etc.
While overall it was very successful, we quickly ran into many of the problems stated above. We had a lot of problems organizing our stories into a higher context, and we had no executive view which would allow client leadership to let us know if we were generally in the right direction. As a result, we wasted a lot of time developing functionality that was never actually used. (Often users on the ground working with agile teams do not have proper executive context, just a fact of life at least in all of my experiences)
As the program started to grow in size with multiple teams, I started looking into use cases, going through a variety of use case books until I came upon Writing Effective Use Cases and Patterns for Effective Use Cases. We started writing use cases according to the advice in these books, and saw great value immediately.
In all other respects, we still followed an iterative process, we developed use case briefs for a large portion of the use cases upfront. These then acted as our user stories in terms of planning, and estimating. The first thing we then did at the beginning of each iteration was to develop scenarios and extensions for use cases assigned to the iteration. Still agile, still iterative, but we used use cases.
Why Aren't These Cases Accepted within the Agile Community?
Throughout the last five years I have subsequently been a lead architect and process lead on no less than five separate projects (some very large and some very small) where I have used these techniques for use cases. I combined these use cases with other agile approaches (CRC, story points, test driven development, etc.) and have found them to be fantastically useful. This whole agile bias against use cases stems from the fact that use cases are probably one of the most abused SDLC related artifact. There are many different ways to do use cases, and from what I've read, most of them are just "wrong". But when done according to the advice found in these two books, they can really support an agile approach. I'm also confused by the agile maxim that you should "do what works", as long as you don't use use cases, never do any upfront modeling, don't use any case tools, etc., etc.
IMHO this sometimes religious bias against other tools can sometimes limit the appeal of agile by nonbelievers. I'm probably going little off-topic and will stop there.
Maybe the whole agile bias against use cases is a reaction against previous BUFD. But I still agree a little bit of upfront thinking is always going to benefit any development effort, as long as the emphasis is not on creating a requirements document, but doing the necessary thinking required to ensure that the right product is developed.
I think use cases can easily mapped to user stories, and can fit into almost any agile process
summary use cases > epics, themes
system use case > regular user stories
use case briefs >user story descriptions
use case details >part of iteration planning, determining the iteration objectives.
I will continue to use use cases on future projects, but combining them with more traditional agile techniques.