User Story Mapping

A lightening talk by Nils Christian Haugen (in Norwegian) on Smidig2008 (Norwegian Agile2008) was on User Story Mapping, as proposed by Jeff Patton. The user stories need a context, which shows how they generate value to the organization. So you have user roles, user activities and user tasks, which may be broken down into user stories.

Isn't this reinventing the Business Use Cases? Perhaps, perhaps not. I think it conveys the same idea, but I find the presentation an interesting layout of Use Case actors, more intuitive and easier to transfer to clients and developers alike. So I like it. Besides, they are devoid of the undeserved bad reputation of Use Cases as being written in stone.

What about epics? Aren't epics the same thing? Well, an epic is like a user story too big to be implemented in one iteration. But once you start implementing it, what then? You probably don't finish it all during one sprint, so it needs to remain, at the same time as parts of it appear as user stories. That creates kind of double messages, since they belong to different levels of description, and this leveling is not captured by the User Story technique. I think Use Case scenarios, Quantified Qualities à la Tom Gilb or User Story Map tasks capture this effect better. They also provide a framework for keeping the big picture in view and assuring that the user stories you pick support each other, and that together they make up a profitable user activity, or Business Scenario.

You may also ask whether this oveall, business level description belongs to the development team. Isn't that the Product Owner's table? I think experience shows that the Product Owner has a hard time setting up and maintaining this kind of plans on his own, and that it is extremely beneficial, if not mandatory, for the team to gain this overall level of understanding. So yes, I think it belongs to the team and serves well to support sprint and release planning as a complement to user stories.