Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Use Cases or User Stories?

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:

Written description of the story, used for planning and as a reminder

Conversations about the story that serve to flesh out the details of the story

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:

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?

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?

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":

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.

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.

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.

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.

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?

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.

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.

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."

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.

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?

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.

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).

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

Maybe you find the following comment is weird, but for me, use-cases and user-stories are almost the same! Yes, the origin and the intention of use for both of them was different. Yet, each one of them, as a requirement tool can provide, when ‘properly’ used, the equivalent results and achieve the same goal. My point is that, if we want to minimize the documentation overheads and lay more on use it as a communication tool, then we can write ‘lighter’ use cases, and still get the benefits ‘providing the context’ of scenarios and extensions. On the other hand, if we want to provide more level of details, as necessary, in user stories, then all cases and scenarios are to be represented in the acceptance tests, which in this case will include the same content of information as use case.So, I see that it just matter of different format! And they both will cover, in that way, the completeness and most of the other issues addressed through out this discussion.

More of couple of points required to be emphasis here:- No one will prevent you to empower your requirements-team with both user stories and use cases and be aware of the two approaches and to select one of them to work with depending on the different situation and project you might have, e.g., , use cases might be more very effective for workflow-automation based project.

- No matter you will choose to apply user stories in your projects or even other tool, it is very important to make sure that your requirements-analysis team be aware of learn concepts and fundamentals behind use cases where they can learn how to address, analyze and manage requirements how and when to focus on normal course of events, deviations in the flows, etc. (and that’s no matter the format will be used)

Some recommended references regard this are Cockburn’s Book “write effective use cases”, “Use Case Pattern” book, and IBM Rational training course“Requirements Management with Use Cases”.

I don’t have much experience in using ‘user stories’ yet, but I have a worry for new BAs who will start their career by writing user stories, without a previous experience or knowledge of the use case concepts, that they will likely have somehow a ‘shallow’ analysis capabilities and they would produce ‘poor requirements’.

I was involved with a project recently where User Stories where adopted but this approach was failing because user stories were written as a high level requirement but the idea that no lower level requirements were required as a 'user story is just a reminder to have a conversation' was adopted.

Therefore just before a sprint the lower level requirements had not been gathered leading to vague acceptance criteria at wrong level.

I became involved and could not put user stories into any context so I split the entire development into a use case survey and we delievered fully dressed use cases for the next sprint.

The development team were really happy with use cases as gives context and info but also wanted user stories just as a mechanism for story point planning and to give them something more meaning than 'Use case XXXX Alternative Flow 1' to write on cards to blue tack to the scrum board thing.

The development team simply took each main flow and alternative flow of each use case for the next spront and created a seperate user story for each and deemed that the acceptance criteria are the requirments within the use case narrative.

The backlog therefore consisted of use cases flows, given a user story description 'As a xxx I want to xxx so that xxx'. And use case requirements listed as acceptance criteria [lower level requirements] that must be considered [tested] in order for the sprint to be accepted.

This rule seemed to work for functional requirements in majority of use cases - there was the odd use where the basic flow was broken into more than one use story [debatable whether the use cases should have been split really!]

Non functional requiements were added as seperate user stories as no use case conversion was required.

This approach seemed to work and now I am wondering whether use cases are better [add more context] or user stories........ but the big lesson learned was that the detail you need [in my opinion] before you start a sprint, is the same whether you use 'use cases' or 'user stories'....you need to think of the user story acceptance sriteria as the lower level requirements that you would describe in a use case narative.

Do people agree - some people still argued that we went too low in detail and that the lower level stuff can be leaft for during the sprint but I strongly disagreed.

I am now on a new project and people are asking what level of requirement detail do you need before a sprint - I keep saying you really need to nail the lower level requiremnents [what must be delivered and tested - acceptacnce criteria] before the sprint starts but live up to the spirit of agile if things change or are fouhnd to be missed during the sprint. However people have argued that this is not agile? Any thoughts?

My thoughts are that you need to be looking at lower level requirements for the next development sprint while the developers are developing the current sprint

I have come to the conclusion that incremental sofwtware delivery is good and that iterative software development is good but from a requirments perspective it does not matter whether it is use case/user story or both as much as it matters about the quality of the requirements.....there is a new method coming out every other week with the justification that lots of projects using the previous method failed but the real reason is probably that there are a lot of crap BAs out there and a good BA will make any method work.