Requirements Management has for a time been a hot topic within the Agile community, and a religious war has seemed imminent between the followers of user stories on one side and use cases on the other. The rebelyell of the user story-buffs have often been “out with the old and in with the new!” – and many have seemingly been against use cases merely because they have RUP written all over them. On the other side we have seen use case devotees in white coats mocking user stories lecturing that this unscientific bumblebee cannot fly.

Lean Magazine has talked to one of the greatest experts on the matter, Alistair Cockburn, who has not only been a leading profile in Requirements Management for twenty years, but also has a moderate view on the pros and cons of the two concepts.

Alistair Cockburn’s engagement in Requirements Management started in 1991. He was working for IBM Research in Zurich and needed a way to return to the United States. IBM had just started the IBM Consulting Group, and was constructing a methodology for its consultants to use.
“At that time it was mostly based on Information Engineering, i.e. dataflow modeling and databases,” Cockburn recalls. “But they needed a track for the emerging Smalltalk and C++ projects – that was my assignment.”

Noun- or verb-based?

During those days, the object-oriented modeling, design and programming parts were relatively obvious: There was the Booch/Rumbaugh school of OO modeling, there was the Cunningham/ Beck/Wirfs-Brock school of responsibility-driven design, and there were the programming languages Smalltalk and C++.

“However, those left a large gap in the area of requirements. It was not clear to me that requirements should be object-oriented just to follow the design being object-oriented.” Cockburn discovered Ivar Jacobson’s 1987 report on use cases from the OOPSLA conference, and found they had a perfect fit for the information he was missing in the methodology:
“When I say perfect fit, what I mean is that object-oriented models are all noun based – they name the nouns in the domain. Use cases are all verb based – they name the actions being taken by the people and the nouns in the domain. Having all verbs or all nouns leaves a big gap in the model. Having use cases tells us what to accomplish; having objects tells us what will accomplish that. In some sense, it is like having the warp and weft in weaving – some threads run vertically, some run horizontally. You need both. Paying attention to that nounverb issue has been a big help to me in navigating the choppy methodology waters. I still use it to this day.”

Getting the big picture

Today, Cockburn always starts with use cases in order to get the big picture. These use cases can be written quite briefly, perhaps two paragraphs to a half-a-page or at worst a page, so this is generally useful inquiry and not onerous writing.

“Without the big picture I (and others) have no idea what we’re trying to build, its shape, size or complexity. I use the discipline surrounding use-case writing to shine a light into dark and hidden corners, and expose potential trouble spots. This shape then guides what happens next.”
Once the “coarse-grained use cases” are in place, Cockburn is “fairly indifferent” as to whether use cases or user stories are used after that.
“It’s very much a question of how much the people involved can keep in their heads and how good their conversations are. I do like to use the discipline surrounding use cases to check for extension conditions and extension handling, and would apply some version of this discipline in all cases.”
However, use cases have one major limitation with short iterations: It is impractical to implement an entire use case in a single iteration.
“Personally, this doesn’t bother me, because I’m happy to put the use case on the wall and simply color the sentence in the use case being implemented in this iteration. Coloring them like this allows me to implement individual sentences or even phrases from the use case set in any order I like, and to always see what’s done, what’s stacked to be done, what’s in progress, at any given time. In this sense I don’t need user stories at all.”
In Cockburn’s experience few other people are willing to do the above coloring. Instead, they prefer to see separate work items listed on separate cards or as separate line items. For these people, cutting the use cases into user stories is pretty much a necessity.

Use cases have limitations

According to Cockburn, there are two occasions when use cases really don’t serve a useful purpose. The first is for CAD/CAM tool-type systems. In these systems, there is no plot line for the story embedded in the use case. There are only many different tools the user can bring to bear.
“In such cases, I would quickly shift from high-level, coarse-grained use cases to features lists (and I wouldn’t even call them user stories, just ‘features’).”
”The second occasion when use cases don’t serve a real purpose is in bug lists and feature enhancement lists. Related, once the system is fairly far along in implementation, the ongoing requests from users look more and more like feature enhancement lists.”
”Again, I wouldn’t call these user stories except in deference to the implementation group if they are in the habit of saying ‘user story’ instead of ‘feature’ or ‘product backlog item.’ In the case of long bug or feature lists, I would just work from the list.”
In contrast to this, Craig Larman – chief scientist at Valtech – claims that he likes user stories because they scale up to really, really large requests (like “implement the entire system”). In a way, both use cases and user stories could be regarded as fractal. Larman makes use of this fractal nature of user stories to break really big projects into manageable pieces, each time using the “marker” characteristic of user stories to defer detail.
“I should say that this works for Craig because he can keep a lot in his head and is good with his conversations. From my perspective,
if a team can’t keep track of which sentence in a use case they’re implementing on a given iteration, they won’t be able to keep track of the fractal expansion of very large user stories.”

Three essential factors

In Cockburn’s opinion, three things are really important in any project: vision, size and context:

Vision

“It is crucial that every team member sees approximately the same end goal. This is more important on agile projects because they write down less and leave more to tacit knowledge. Therefore, every project – agile or not, using Scrum or not – should have written down and posted in plain sight a short description of what the system is supposed to do and how it is supposed to help its users and stakeholders. Anything over a page long is too long.
“Ideally, the vision or mission statement captures some emotional feeling to help the developers tell whether they’re on track or not. For my new web site design, we’re using, ‘Get pleasantly lost in all the articles and content.’ Our first user test produced the response, ‘It’s very nice and clean, but I can’t see how to get pleasantly lost in here.’ Because of the vision statement, our viewer knew immediately what to comment on, and we had a direct idea in which direction to make changes. Other ones might be like, “Slide the buyer effortlessly along the conveyor belt to finishing a purchase”, or ‘Ensure the nurse NEVER gives a patient the wrong medication.”

Size

“Everyone has an idea of the order of the task at hand, whether this is going to be a 10 work-month project or a 250 work-month project. All too often with agile projects, I see a ceiling line that rises faster than the programmers can work. This makes the sponsors nervous and the programmers depressed.
”I’ve written that I like use cases because they reveal the size and shape of the product. If you’re not using use cases, go for some other technique that will hint at the approximate size of the final system, so the sponsors can make appropriate funding and staffing plans.”

Context

”The programmers, UI designers and testers know how each product backlog item, sprint item or user story fits in the work or operation of the user. This context helps them make many small design decisions along the way, or even challenge feature requests.”