Unifying User Stories, Use Cases, Story Maps: The Power of Verbs: The Simplifying Series

By Alistair Cockburn

Use cases, user stories, and story maps have been circling like comets, competing for the same energy of the same people at the same time. There is something obviously similar about all three but just exactly what isn't obvious.

 

In this ground-breaking book, Dr. Alistair Cockburn, noted expert on all three techniques, co-author of the Agile Manifesto, and author of the definitive work Writing Effective Use Cases, puts them all together, showing how they both complete and complement each other. Cockburn starts by attending to the seven key concepts without which none of them can be written well, and with mastery of which you can move freely between them. From there he breaks down user stories, then use cases, then story maps one by one, in clear and practical terms. Finally, he shows how to move between them, making them more effective in combination.

 

The book contains exercises and drills, making it suitable for self study and classroom teaching.

• Language: English
• Publisher: Alistair Cockburn
• Release date: May 7, 2024
• ISBN: 9781737519775

Book preview

Preliminaries

The series and this book

Twenty percent of the technique gets you eighty percent of the value, so they say. So why not learn a good, juicy twenty percent first and get running fast? Then, level up with other techniques that take you into the corners that the first set doesn't cover.

My idea with this series is to cherry-pick a relatively easy but very useful starter kit for various specialties. Project management is an entire career, but there are things that can help you get started and quite far right away. Software design is an entire career, but there are techniques that can help you get started and sort your way through numerous seemingly different puzzles. Use cases and user stories are wonderful but complicated. There is surely a starter kit that gets you very far.

Those are the ideas I have for this series.

This particular book is for user stories, use cases and story maps. They are dreadfully misused. With this little book, I hope to clarify what makes them work, what makes them work well together, and to give you a running head start on using them well, separately and together.

Let's take a look.

Alistair Cockburn

May 6, 2024

Why this book?

Ivar Jacobson invented use cases around 1987. I found them to be the missing requirements piece for the methodology I was writing at IBM. In 1992, I flew to Stockholm to learn from Ivar and his team.

Kent Beck invented user stories. In a 1995 round table on use cases, Kent Beck said (approximately), Just walk down the hall and ask your users what they want. Write that on a card, come back, program it, show it to the users, revise, show, until done. That practice became part of Extreme Programming in the subsequent years and is what we have come to call user stories.

Jeff Patton invented story maps in 2004. Unsatisfied with use cases (too much solo writing) and user stories (too sloppy), he created story maps to get something that was fully agile, made use of user stories, was both collaborative and showed a coherent user flow.

Mike Cohn coined the idea of an epic in 2004. An epic is like a user story, but taking longer than an iteration to develop. It is largely a placeholder for future investigation and decomposition.

These four terms have been circling our industry like comets, not quite touching. There is something obviously similar about all four, but just exactly what isn’t obvious. They also compete for the same energy of the same people at the same point in a project, so they compete with each other in some overlapping fashion.

A few people seem to be able to navigate freely between them, but most people get lost trying to do any one of them well, let alone all four.

I have taught all of them, and until recently, couldn’t quite nail down how they complete  and complement each other.

I think I finally can (hence this book).

They all hinge on the same core concepts, without which you will make a mess of any of them; and with mastery of which you can move freely between them.

My hope with this book is to free you up to choose a use case here, user stories there, epics that might or might not be use cases, and a story map backed up by those use cases.

Or just choose any one, and don’t make a mess of it.

Organization of the book

This is designed to be a practice book as well as an instruction book. With that in mind, there are these major sections:

Key concepts for all of them

User stories

Use cases

Relating user stories and use cases

Story maps

Moving back and forth between them

In every section, I provide the key ideas for each, discussion, the fine print, and some drills.

You can’t make sense of the book if you don’t master the key concepts for all of them. After that, you can pretty much pick up any section you like, and dip into the other sections to backfill as you need.

There is a table at the start of every idea, giving a capsule summary. I collect the tables at the end as the summary and  a quick reference guide.

What the heck is a user story, use case, etc., anyway?

A user story is a short phrase or sentence that captures a user’s wants. Anything they can notice (including speed) counts. It is not intended to be a complete spec, it is intended to live in a conversation between a user and a developer. They discuss what the short phrase should intend. The developer goes and programs it up, shows it to the user, revises the work, repeats, etc., until the user says, Yes, that’s good. A user story should be small enough to fit into an iteration.

An epic is a fat user story. A user story is supposed to be small enough that the development team can finish all of it in a single iteration. Clearly, not all user requests might fit into just one iteration. The term epic indicates that this item is big and will need to be broken down.

A use case is a special writing format to describe the interactions needed for a user to achieve a goal they might have. Unlike a user story, it is written with full sentences, failure conditions, how those failures are patched up (or not), and what happens at the end. It is a full spec of the behavior of the system with respect to that user goal.

A story map is a 2-dimensional grid of user stories (and epics) in which every type of user gets their own column. The top row(s) of the grid show the user tasks needed to complete a business process. Each column, below that, contains all the user stories involved in delivering the higher-up cards.

Let’s go investigate!

1: Key concepts for all of them

User stories, use cases, story maps, are all verb-based, just with varying degrees of elaboration or placed on the wall differently.

Here are the key concepts to master. You will need these for anything you do with user stories, use cases, story maps ... actually pretty much anything. Without these, everything’s a mess. You will stumble through murky requirements and murky discussions.

With these, you will see quite easily how to fit a user story into a use case, or cut a use case into user stories, how to move back and forth between story map, use case and user story. They are all remarkably similar, once you have the concepts in place.

1.  Verbs imply durations.

All verbs take time. Both you and your reader probably have a similar sense of time for most verbs. When you say or write get cash from an ATM, you already have in mind how long that takes: probably 2-5 minutes. When you write manage my investment portfolio, you don’t expect that to take 2-5 minutes. It is an ongoing activity that might not end for years. When you write: select a quantity (of an item),, you already understand that it should be a few seconds, not several minutes.

I use the metaphor of altitude to indicate the intended time needed for a verb. Very high-level verbs take days, weeks, months, years. Very low-level verbs take seconds or less.

Interestingly, people around the world seem to have a common understanding of what an ordinary user task might take in an ordinary business context: 2 – 20 minutes. That covers ordinary human activities like Buy a , Fill the car with gas, Update my profile, and so on.

Experienced readers here will recognize that these actions map to atomic business processes or database transactions.

The biggest mistake that