‘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.
WORKSHOP CASE EXAMPLES
There is some interconnectivity between the Story Mapping exercise and the so called Magic estimation. Two possible cases for a workshop:
1. Waking up
Setting: you act a family of 2 and 2 little kids (one primary school, one baby), both parents working
Groups: Two groups, one acting the female parent, one the male parent
First step: both group (for their gender) write down on post-its anything to be done between waking up and leaving the house
Second step: cluster the items in time
Third step: vertically slice/break down the items in parts
Fourth step: horizontally slice based on amount of time. As facilitator draw a line (with tape) below the post-its and ask what can be achieved in just 15 minutes. Repeat for 5 minutes.
Last step: have a plenary discussion (and some laughs). What lessons can be learned for our own work context and what actions do we see?
2. BBC app
Setting: you’re making the brand new app for the BBC
Groups: three groups, divided over the app categories: news, sports, weather
Step 1: every group comes up with as much nice features as possible within their category
Step 2: think of technical enablers needed to make this happen
Step 3: on the floor*, with tape, set out a matrix with on one axis ‘Value’ and on the other ‘Impact’
Step 4: Let the teams plot their pbi’s in the matrix
Step 5: plenary discussions, for example:
– what do we have made?
– what interconnectivity is there between items (you can use red wire to show these) of cluster
– what is the execution order?
– what can be put in the trash bin?
– what lessons can be learned for our own work context?
– what actions do we see?
Note that the BBC app workshop is officially named ‘Magic estimation’.
* Test if removing the tape can damage the (wooden) floor…