Use Cases or User Stories?

Murali Krishna tells us:

Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is.

The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with.

Murali mirrors what many in the Agile community believe - that user stories are the only/best way to go and points us to an article by Mike Cohn, Advantages of User Stories for Requirements where Mike defines user stories:

Each user story is composed of three aspects:

1. Written description of the story, used for planning and as a reminder
2. Conversations about the story that serve to flesh out the details of the story
3. Tests that convey and document details that can be used to determine when a story is complete

and then specifically contrasts user stories to the other well-known requirement technique, use cases:

Because stories exhibit some of the same characteristics of use cases or traditional requirements statements, it’s important to look at what distinguishes stories from these earlier requirements techniques. These differences can lead to many advantages for user stories.

User stories emphasize verbal communication. Written language is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way. For example, at lunch recently I read this on my menu: “Entrée comes with choice of soup or salad and bread.”

That should not have been a difficult sentence to understand, but it was. Which of these did it mean I could choose?

• Soup or (salad and bread)
• (Soup or salad) and bread

We act as though written words are precise, yet they often aren’t. Contrast the words written on that menu with the waitress’ spoken words: “Would you like soup or salad?” Even better, she removed all ambiguity by placing a basket of bread on the table before she took my order.

So it seems pretty clear that user stories are superior.  But is that really the case?  Alistair Cockburn, another well known and respected figure in our community, still uses use cases as he sites several issues in his experience that happen when you go to user stories:

1. User stories and backlog items don't give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?
2. User stories and backlog items don't give the project team any sense of "completeness" – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?
3. Related to completeness, user stories and backlog items don't provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don't) – I keep hearing this complaint, "We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role." No, they don't have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment - the extension conditions are usually detected mid-sprint, when it is too late.

Alistair then goes further than telling us "why not user stories", and focuses on "why use cases":

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have thought through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

Things aren't as clear cut as some would have us believe.  What should we do?  Is what we are doing working for us?  Is there one right way?  Are there two right ways?  Or, perhaps, does it depend upon context?  Could it be that use cases are right for some circumstances, and user stories are right for another - which ones?  Could it be that they are not really that different - that a use case (perhaps) embodies several user stories because a use case scenario looks, feels, and breathes like a user story?