I was planning to propose a very small adaptation to Jeff Patton’s user story mapping. I’m going to do it, but while writing I found myself highlighting three key learnings from the three most common populations in an agile transformation in my environment. And I now think that this feedback has more value than the small adaptation I’m making to Jeff Patton’s user story mapping, but I’ll tell you about it anyway.

The learnings

The learnings I want to discuss are key in the sense that they change commonly accepted or encountered postures. They’re not necessarily the most important, but they are important because they’re representative of the changes induced by a modern Agile approach.

Business learning: knowing how to break down

In my let’s say classic process of defining needs after workshops like design thinking, lean startup or innovation game (lean canvas, persona, remember the future, empathy map, etc.), after these workshops I articulate two maps (see this article). Impact Mapping provides the strategic axes, User Story Mapping defines a tactical approach. But both seek to obtain the same type of result: prioritize (value) small autonomous sets (finished things) that make sense and will allow for rapid feedback. This is the objective of business people: valorize and validate their value proposition as early as possible. Thus they need to learn how to prioritize, but especially how to break down into small elements that make sense. Break down at the feature level, break down at the level of a coherent set to propose.

Technical learning: knowing how not to make technology a complication

The technical learning is to not make technology a complication, that is to offer value creation a foundation that guarantees it can express itself without worrying about the technology itself. In practice, and in IT environments, this concretely translates into learning continuous integration platforms, continuous delivery, automated testing, test driven development, etc. This is perhaps the hardest learning because it’s often hindered by the existing system.

Management learning: knowing how to let go: self-organization and uncertainties

The management learning is well known, it’s the change in posture between boss, manager, boss, and servant leadership, facilitator. This takes two forms: facilitation (helping, supporting, advising, etc.), and letting go—this one is the hardest to learn because it’s often quite a marked change in posture. This “letting go” will need to be expressed primarily in two ways: letting self-organization happen and accepting uncertainties (of budgets, deadlines, the world, complexity, the environment, etc.).

User Story Mapping

And if I come back to this user story mapping, the difficulty for business people is breaking down into small pieces that make sense (which we prioritize by value, but that’s less difficult). Generally the steps of a user story mapping are: we lay out a main line of major features, or behavioral or chronological steps, from left to right. The first reading direction is therefore from left to right, this is the main axis. Then we break down each of the bricks of this axis vertically: from top to bottom, in order of importance, we align the elements that will allow us to more or less constitute the header element of the horizontal line. We therefore then have two reading directions: primary from left to right, secondary from top to bottom: the detail necessary to realize the main element. At any time we can place above the main horizontal elements alerts, vigilance points, open questions, which will make us aware for what follows.

It hurts but it works

The next step is crucial: it involves—for example through a MoSCoW ordering (Must have, Should have, Could have, Would have, that is: I must have, I should have, I could have, I would like to have)—cutting up the matrix that has appeared. We cut by small sets to deliver that make sense. Often difficult for business people, who want more than they can have. Initially it’s difficult to make them aware of the importance of not going too far before getting feedback, of not going too far before benefiting from the value already created.

So it’s difficult to ask them to move elements down from “must have” to “should have”. Many things remain in “must have”, which often remains too “fat”, too “bloated”, to be effective enough. I struggled to get elements moved down into the “should have” line, explaining that we’d do them anyway, just later, and with the feedback and value of the “essential” in between. Often in vain.

And then just with a small cognitive trick I freed up situations: they had to move the elements up, not move them down. Since I understood this, when the user story mapping is coming to an end I quote the founder of LinkedIn who said—I believe, from memory—“if you feel comfortable when you release your product it’s too late”, and then I free up a space above the “Must Have” block that I call “It hurts but it works” and I ask business people to place there what hurts but works anyway. Above. The movement is very different. And indeed it hurts but it works.

Example of User Story Mapping (which comes from this article), click to enlarge (consider the product versions as the “must have”, “should have”, etc…):