User story maps and use cases

I am three days old in my new position at my new employer, Osiris Data, and one of many exciting things that happens here are the always ongoing discussions on how we do things around here.

This time, I asked Terje on what they expect from design and inception, and we quickly went into a friendly debate on Use Cases in general and how to write them.

Two tings I came to remember during the conversation seemed to struck a chord:

1. The new user story backlog is a map.
2. Why I still use use cases.

Jeff Patton explains why we need a user story map:

Arranging user stories in the order you'll build them doesn't help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question "what does the system you're building do?"

And Alistair Cockburn writes about why he still use use cases:

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” ... and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

And those three things he refers to are:

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.