‘The assumption is the mother of all fuck-ups!’
Strong language, often from the mouth of the archetypal entrepreneur (turtleneck, horn glasses, sneakers). But that assumptions cost money – a lot of money – is clear to most people. Agile working is also about exchanging assumptions for truths . Also those truths you would rather not hear *. And these truths are in the possession of the end user of your solution. But what does the user encounter? What does he see as the happy flow? Where does it get stuck? Where does he drop out? User story mapping helps to provide insight into the customer journey.
UX design
User story mapping is a form of User Experience Design. The first to come up with this technique was Jeff Patton. The technique is easy to explain, but does require some time and thought.
In short, you make the customer journey transparent by working out a grid of user stories. How does the user move through your app? What steps does your customer go through when buying your product?
As a first step , you make a rough overview in two dimensions:
- You work out the moments in the customer journey on the horizontal axis.
- You hang the items that belong specifically to this part on the vertical axis.
Source: Manifesto.co.uk
In the second step we refine. You go deeper into the parts and create additional items by breaking large items into smaller chunks. And you then sort these by ‘sequence’. For example, the customer must first enter the postcode before you can perform the postcode check (for the automatic completion of address data). That determines the vertical ranking. Indeed, just like a backlog.
Source: Manifesto.co.uk
In the third step we will slice horizontally . We have arranged the story map so that we see it as a cake with different layers. Each layer provides working functionality (minimal viable product) and therefore has direct value. You start with the most important layer (the bottom of the cake) and work your way up in iterations until the whole cake is finished **. This way of working makes the epic manageable. And, more importantly, you keep room for change. The cake grows with the wishes of the eater. If he suddenly turns out not to like chocolate at all (the assumption), but rather merengue, you’re glad you didn’t bake the whole cake for him.
Source: Manifesto.co.uk
Start small
Suppose you have come up with an exchange service for modems. At moment X, the delivery person (actually the ‘haler’) of your company will visit the customer. He receives a new modem and immediately gives his old modem. This saves your organization and the customer time and money. A wonderful solution. But now get inside the customer’s mind. Has it always neatly packed its old modem and is ready in the hall, complete with all plugs? Or he keeps the modem connected until the last second and does not start disassembling the modem until the moment the delivery person arrives with the necessary curses and views. What would you do?
The customer journey therefore has many turns. So start small. I first recommend mapping the Happy Flow (the ideal customer journey). As soon as you have the main points correct, you can add exceptions. These are often so decisive that it is best to make them as separate story maps. By analogy with user stories you then have an epic map with child maps below.
Extension: Backlog dimensions
The weakness of the Story Mapping technique is that your choices depend on the angle you choose. As an in-depth look at the technology, I therefore add Backlog Dimensions. It is fun and useful to discuss the different perspectives one by one during story mapping. This produces different outcomes / choices.
An example: if you map a story to the dimension Value, you make different choices than when you look at Full-time. Something can have the highest value, but it depends on the existence of some other functionality (which sometimes has a negative value).
Story mapping dimensions ( Gerjon Zomer, 2018 )
This technique with backlog dimensions seems very complex and abstract, but if you go through the above overview during story mapping, you will see that it makes very sense. And useful.
Tip : user story mapping is often used when devising a new epic. But it is a useful exercise for the entire existing backlog. Occasional story mapping is very useful to see if you are still doing the right things.
* If you still notice a longing for ostrich politics with story mapping (‘we’ll figure that out later’) then use the Knock Out 5 to get everything above water that you would rather keep below the surface.
** As you understand, having a feature team is essential because a component team does not oversee the entire customer journey but only 1 part of it.