‘The assumption is the mother of all fuck-ups!’
Ferme taal, vaak uit de mond van de archetypische ondernemer (coltrui, hoornen bril, sneakers). Maar dat aannames geld kosten – veeeel geld – is de meeste mensen wel duidelijk. Bij agile werken gaat het ook om het inruilen van aannames voor waarheden. Ook die waarheden die je liever niet hoort*. En deze waarheden zijn in het bezit van de eindgebruiker van je oplossing. Maar wat komt de gebruiker tegen? Wat ziet hij als de happy flow? Waar loopt hij vast? Waar haakt hij af? User story mapping helpt de klantreis inzichtelijk te maken.
UX design
User story mapping is een vorm van User Experience Design. De eerste die met deze techniek op de proppen kwam was Jeff Patton. De techniek is simpel uit te leggen, maar vergt wel wat tijd en denkwerk.
In het kort maak je de klantreis inzichtelijk door een raster van gebruikersverhalen uit te werken. Hoe beweegt de gebruiker door jouw app? Welke stappen doorloopt je klant bij het kopen van jouw product?
Als eerste stap maak je een grof overzicht in twee dimensies:
- Op de horizontale as werk je de momenten in de klantreis uit.
- Op de verticale as hang je de items die specifiek bij dit onderdeel horen.
Bron: Manifesto.co.uk
In de tweede stap verfijnen we. Je gaat dieper in op de onderdelen en maakt extra items aan door grote items op te delen in kleinere brokken. En je sorteert deze vervolgens op ‘volgtijdelijkheid’. Zo moet de klant eerst de postcode ingeven voor je de postcodecheck (voor het automatisch aanvullen van de adresgegevens) kunt uitvoeren. Dat bepaalt de verticale rangorde. Inderdaad, net als bij een backlog.
Bron: Manifesto.co.uk
In de derde stap gaan we horizontaal slicen. We hebben de story map zo geordend dat we deze zien als een taart met verschillende lagen. Elke laag levert werkende functionaliteit op (minimal viable product) en heeft dus directe waarde. Je begint met de belangrijkste laag (de bodem van de taart) en werkt zo in iteraties omhoog tot de hele taart af is**. Door deze manier van werken maak je de epic behapbaar. En, belangrijker, je houdt ruimte voor verandering. De taart groeit mee met de wensen van de eter. Als die opeens helemaal niet van chocolade blijkt te houden (de aanname), maar van merengue, ben je blij dat je niet de hele taart voor hem gebakken hebt.
Bron: Manifesto.co.uk
Begin klein
Stel: je hebt een omruilservice bedacht voor modems. Op moment X komt de bezorger (feitelijk de ‘haler’) van jouw bedrijf langs bij de klant. Die krijgt een nieuw modem overhandigd en geeft gelijk zijn oude modem mee. Dit scheelt jouw organisatie en de klant tijd en geld. Een prachtige oplossing dus. Maar kruip nu eens in het hoofd van de klant. Heeft deze altijd netjes zijn oude modem ingepakt klaarstaan in de gang, compleet met alle stekkers? Of houdt hij het modem tot de laatste seconde aangesloten en gaat hij pas op het moment dat de bezorger komt aan de slag met het demonteren van het modem met de nodige vloeken en zichten. Wat zou jij doen?
De klantreis kent dus veel afslagen. Begin daarom klein. Ik adviseer allereerst de Happy Flow (de ideale klantreis) te mappen. Zodra je die op hoofdlijnen kloppend heb kun je uitzonderingen toevoegen. Vaak zijn die zo bepalend, dat je ze het beste als aparte story maps kunt maken. Naar analogie van user stories heb je dan een epic map met daar onder child maps.
Uitbreiding: Backlog dimensies
De zwakte van de Story Mapping techniek is dat je keuzes afhangen van de invalshoek die je kiest. Als verdieping op de techniek voeg ik daarom Backlog Dimensies toe. Het is leuk en nuttig om bij het story mapping een voor een de verschillende invalshoeken te bespreken. Dit levert namelijk verschillende uitkomsten/keuzes op.
Een voorbeeld: als je story mapt op de dimensie Waarde, maak je andere keuzes dan wanneer je kijkt naar Voltijdelijkheid. Iets kan de hoogste waarde hebben, maar afhankelijk zijn van het bestaan van een andere functionaliteit (die soms een negatieve waarde heeft).
Story mapping dimensies (Gerjon Zomer, 2018)
Deze techniek met backlog dimensies lijkt heel complex en abstract, maar als je tijdens het story mappen de bovenstaande overzicht afloopt, zul je zien dat het heel logisch wordt. En nuttig.
Tip: user story mapping wordt vaak ingezet bij het uitdenken van een nieuwe epic. Maar het is een nuttige exercitie voor de hele bestaande backlog. Af en toe story mappen is heel nuttig om steeds te zien of je nog de juiste dingen doet.
*Merk je ook met story mapping toch nog een hang naar struisvogelpolitiek (‘daar komen we later wel uit’) gebruik dan de Knock Out 5 om alles boven water te krijgen dat je liever onder de oppervlakte zou houden.
** Zoals je begrijpt is het hebben van een feature team essentieel omdat een component team niet de hele klantreis overziet maar slechts 1 onderdeel ervan.
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…