Use Cases or User Stories?

Posted by Amr Elssamadisy on Jul 28, 2008 05:25 AM

Community

Agile

Topics

Agile in the Enterprise,

Agile Techniques

Tags

User Stories,

Use Cases

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?

RelatedVendorContent

Agile Metrics Tracking and Mingle Podcast + Transcript

Six Free Project Management Certification Training Courses

Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21

Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)

Agile Tool Evaluation Guide

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

1. Back to top

   Well...

   Jul 28, 2008 10:03 AM by Michael Bartyzel

   Use cases were intended to be proxy between users, analysts, programmers and testers. But I've never met a customer who would to learn yet another bulk of terms (actor, use case, extend, include, etc.) especially for me. They prefer drawings of the user work process with forms and html sketches.

   Reply

2. Back to top

   Re: Well...

   Jul 28, 2008 1:19 PM by Amr Elssamadisy

   So you prefer neither. No use cases and no user stories? Or user stories to drive all of the other things like forms, sketches, etc....

   Reply

3. Back to top

   Use Cases are Waterfall

   Jul 29, 2008 1:26 AM by Peter Thomas

   Pretty sure I can debunk all of Alistair Cockburn's points for example:

   User stories and backlog items don't give the designers a context to work from

   They don't really need to. The problem with Use Cases is the attempt to capture *everything* in ceremonial detail so that the project team can go back to their cave and work in waterfall mode.

   User Stories should be seen as a tool to get to the goal which is: working software (not loads of word documents).

   But there is a catch: the user has to be continuously available and ideally "looking over your shoulder". Any questions from the development team about "context" or "completeness" that come up during development have to be answered. But as all agile proponents understand, this is far better than Big Upfront Design. I agree that User Stories emphasize verbal communication.

   I still don't understand the difference between "includes" and "extends" in the context of Use Cases. Glad I don't need to anymore. Heh.

   Reply

4. Back to top

   Re: Use Cases are Waterfall

   Jul 29, 2008 4:34 AM by Frode Rystad

   A couple of months ago, I would have wholeheartedly agreed with you on your statement that Use Cases are Waterfall.
   
   I myself boldly stated that "RUP is waterfall" to a group of my colleagues. One of them responded, "Frode, you must never say that!" We had previously worked together on the same "RUP" project using Use Cases to gather requirements, but she had been longer in the business than me. Then she elaborated, "RUP was never intended to be waterfall - it just often gets practiced like that."
   
   Then she told me about an article Craig Larman wrote in 2002, "How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering".
   
   The article is an excellent read, and explains what many do wrong, and how to use RUP and Use Cases more agile. I highly recommend reading it!.

   Reply

5. Back to top

   Re: Use Cases are Waterfall

   Jul 29, 2008 4:45 AM by Amr Elssamadisy

   But there is a catch: the user has to be continuously available and ideally "looking over your shoulder". Any questions from the development team about "context" or "completeness" that come up during development have to be answered.

   Actually, user stories, when they start to number in the thousands, get confusing for the customers also. Here's a report from an early ThoughtWorks project: Recongizing and Responding to Bad Smells in XP that shows many of the things that went wrong with our first XP project. We learned and adapted, but notice that one of the things are keeping track of the user stories. Now, use cases, on the other hand, are usually one or two orders of magnitude in number less. And you are right, they get large quickly. But here's the point - it is the REQUIREMENTS that are huge. So, how do you keep track? I find it very hard to dismiss Alistair Cockburn's comments - not because he is a big name - but, from the beginning, his work has been focused from projects and clients he's worked with.

   Reply

6. Back to top

   Re: Use Cases are Waterfall

   Jul 29, 2008 6:17 AM by Peter Thomas

   @Frode Rystad

   Thanks for the link, I did go through the PDF and it is useful. It may be so that RUP was never intended to be waterfall. However I think we both agree (and at least in my personal experience) that too many RUP projects end up smelling of waterfall. Many organizations attempt to use RUP as a way to standardize processes across the enterprise and this ends up falling into the "one-size fits all" trap.

   @Amr Elssamadisy

   Thanks for the link. Agree, dismissing Alistair Cockburn's arguments is a little presumptious - but his opinion on Use Cases can hardly be called unbiased. Anyway, for the sake of discussion...

   If the requirements are huge, I would argue that you have a bigger problem with Use Cases. I've seen too many projects where just updating the Use Case documents to reflect the changing requirements was a tiresome affair.

   Also, this may not be in keeping with the original "spirit" or RUP or whatever: but haven't you seen projects where at the end there is a frenzied updating of Use Cases so that they match what is shipped.

   I guess the challenge of managing large requirements is why Thoughtworks has come out with a tool like Mingle, right?

   Reply

7. Back to top

   User Stories

   Jul 29, 2008 11:50 AM by Prashant Gandhi

   Both have good and bad points. User stories do use a lot of structure from the use case world such as context and scenarios. But for me, the user stories work the best. Alistair Cockburn may have been lucky to find a customer who knew all the 240 use cases to be implemented, but my experience tells me that the customer does not always know what they want. User stories as a placeholder works best in such a case. And if the customer does not remember the reason for the story at a later date, it probably wasnt such an important story in the first place. User stories thus allow the analysis work to be thus neatly distributed over the course of project and allow for the "discovery" of new features, which are far more valuable than just working with a static list.

   Reply

8. Back to top

   Missing the point here...

   Jul 30, 2008 2:05 PM by William Martinez

   I think the comments are missing the point somehow. It seems Use Cases vrs User Stories melts down to a battle between agile and water fall, when none of them represents either one!
   
   You can still do water fall using a user stories, and do a perfect agile development using Use cases. That is not the point. The point is the actual focus on the need to be solved, and how is that captured.
   
   I may not care how strict is the use case structure, the main focus is on what is to be done. With user stories, you care about what the user do. Two very different points of view, and I may venture and say they are complementary!
   
   Yes, Alistair is right when he says the user story lack the "how" that allows the user to understand the actual effort it will required, but that how is useless to most of clients that want to see (or only understand) the "what".
   
   I may want to start with user stories as a "needs" capture, and then evolve the stories into use cases (the name is a little misleading, I grant that) that will define actual goals for the system. And stop all the thoughts there: if you want an agile use case, we need to get rid of formality and even completeness, or at least wait until we have enough information to decide, but earlier enough so it is not a too late decision.
   
   So the question is not about who usually uses each approach and how bad their reputation is, it is about the actual usability of the approach, for all stakeholders (developers, clients, users, managers and etc).
   
   
   William Martinez Pomares.
   Architect's Thoughts

   Reply

9. Back to top

   Re: Use Cases are Waterfall

   Aug 1, 2008 8:47 AM by regis pezous

   Hi I do not agree you when you say that developer don't really need the context, one of the main agile item is the "shared vision", and to succeed you will need on a day to day basis to replace almost each dev in this long term vision. Also you are highlighting the ceremonial approach of UC, but at the end by staying pragmatic you can can just focused on the main value of UC, and as an BA I always start by the summary, the detailed main success scenario and only the name of main extensions, and most of the time it's enough!! At then end we are using the both, UC for Business validation and US for planification Au revoir Régis

   Reply

• Older >