Stel je voor dat je een tool bezit die je in de gedachten van de potentiële klant van je product brengt, zijn gedrag voorspelt en hem naar de uitkomst leidt die je voor hem hebt voorbereid?
Story Mapping is een methode die bedacht is door Jeff Patton en helpt je om een duidelijker beeld te geven van de User Stories. Dit stelt je in staat om een betere Product Backlog te verkrijgen en zorgt er daardoor voor dat een Agile (Scrum) project beter verloopt. Story Mapping is een visueel hulpmiddel dat ervoor zorgt dat software beter functioneert en in beter aansluit bij de wensen en verwachtingen van gebruikers. Hieronder lees je hoe het werkt en hoe jij er je voordeel mee kan doen.
Laten we eerst stilstaan bij een aantal fundamentele zaken rondom het development proces. Vaak wordt er gewerkt met een Product Backlog, hierin staan alle verlangde functionaliteiten van een product. Deze bestaan uit zogenoemde Epics (de grotere doelen) en ‘stories’ (sub-doelen van het grotere doel).
Een Epic is bijvoorbeeld: zorgen dat de (mail) inbox gemanaged wordt. Stories zouden in dit voorbeeld zijn: het verwijderen, beantwoorden en opstellen van mails. Het in kaart brengen van deze stories, bij voorkeur op de meest functionele manier, is wat Story Map genoemd wordt.
Door Story Map toe te passen, verplaats je je in de wensen en gedachten van de gebruiker. Dit stelt je in staat om functionaliteiten te ontwikkelen die aansluiten op diens wensen. Daarnaast is het mogelijk om een groter project in kleinere projecten op te knippen. Dit maakt een gezamenlijke aanpak makkelijker en laat functionaliteiten opdelen in kleinere releases, waardoor er meer en snellere iteraties mogelijk zijn. Dat maakt het een effectieve methode.
Story Mapping bestaat uit onderstaande stappen. Om deze stappen concreter te maken, gebruiken we een product dat je misschien wel eens gebruikt hebt: de Appie-app van Albert Heijn.
Stap 1: Het concept (de vraag achter de vraag)
Het is logisch om te veronderstellen dat het nodig is om een app te bouwen, een one-pager (een website die niet uit sub-sites bestaat, maar in een keer door-scrolt) of een andersoortig product te ontwikkelen. Stel jezelf liever eerst de vraag achter de vraag. Vaak wordt het doel namelijk met het middel verward. Focussen op het middel is vaak niet de oplossing. Zo richt je je op de vraag achter de vraag:
– Wat is het probleem dat je wil oplossen? (Dat is de vraag)
– Wat is daarvoor nodig? (De vraag achter de vraag)
In het geval van de Appie-app zou het probleem de kloof tussen digitaal en de fysieke winkel zijn. Om consumenten toch naar de winkel te krijgen, is het nodig om informatie over de winkels te communiceren, aanbiedingen en relevante content. Albert Heijn beschikt daar al over: de recepten van de Allerhande zijn dan ook in de Appie-app te vinden.
Stap 2: Gebruikers (persona’s) identificeren
Meer dan eens is er een app of website in het leven geroepen, die niet aansloot op de verlangens of verwachtingen van de doelgroep. Daarom is het nodig om te werken met zogenoemde persona’s. Dit zijn de (verlangde) gebruikers van het product dat ontwikkeld wordt. Het is heel goed mogelijk om verschillende soorten gebruikers te hebben en dus met diverse persona’s te werken.
In het geval van de Albert Heijn-app zou je kunnen denken aan een onderscheid tussen dagelijkse gebruikers (zoals gezinnen) versus onregelmatige gebruikers, die bijvoorbeeld meer Bonus-gedreven zijn. Hoe kunnen beide groepen, in dezelfde applicatie, een zo goed mogelijke gebruikservaring hebben? Loop het resultaat van het Story Mapping dan ook door, terwijl je beide doelgroepen (of persona’s) in het achterhoofd houdt. Wij streven er daarbij naar om zoveel mogelijke persona’s te identificeren, zodat er geen mogelijke gebruiker vergeten wordt. Merk op dat ook de admin een mogelijke gebruiker is.
Stap 3: Eerst de hoofdlijnen (Epic’s)
Het ontwikkelen van een digitaal product start met het bepalen van de functionaliteiten. Deze grotere doelstellingen worden Epics genoemd. Het is een beetje flauwe woordspeling op het woord Story (de kleinere doelen of functies), want het drukt een verhaal uit dat ‘episch’ groot zou zijn. Een Epic helpt echter wel om context en perspectief te bieden aan de Stories en draagt in dat opzicht bij aan het ontwikkelen van de Stories. Niet voor niets wordt de Epic vergeleken met de ruggengraat en de Stories met de rest van het skelet: het een ‘ontspruit’ uit het ander.
Een Appie-app maakt het onder meer mogelijk om te zoeken naar vestigingen (en de openingstijden van die vestigingen), recepten, assortiment en bonus-aanbiedingen te raadplegen. Dit zijn functionaliteiten die voor iedereen te begrijpen zijn. Die Epics vallen verder weer uiteen in kleinere Stories, zoals het scrollen door de verschillende recepten te filteren op bijvoorbeeld allergieën of ingrediënten.
Stap 4: De Stories (in kaart brengen)
‘Onder’ de Epics zijn de Stories te vinden. Dat geldt in twee opzichten. Een Epic valt uiteen in verschillende Stories: het zijn alle onderdelen (de losse functionaliteiten) die het geheel (de complete functie) mogelijk maken. Bij Story Map worden de Stories vaak ook fysiek onder de Epics geplaatst.
Wil je bezoekers van de Appie-app het mogelijk maken om te zoeken op fysieke winkels van de Albert Heijn? Dan zijn hiervoor onder meer de volgende Stories nodig: locatie van de gebruiker (kunnen) vaststellen, een kaart/Maps-omgeving laden, winkels weergeven, informatie over winkels weergeven en het mogelijk maken om te zoeken op de locatie van de winkels.
Stap 5: Prioriteiten stellen
De bedenker van Story Mapping, Jeff Patton, vindt het onzin om van sommige Epics (delen van de ruggengraat) een prioriteit te maken. Vergelijk het met de ontwikkeling van een auto, waarbij je ook geen onderscheid maakt tussen de ontwikkeling van een motor of rem.
Onder deze Epics, op het niveau van de Stories, is het echter wel nodig om prioriteiten te stellen. Maak een onderscheid in vier niveaus van urgentie en noem het – in navolging van de MoSCoW-methode – een verschil tussen:
- M – must haves: noodzakelijk;
- S – should haves: wenselijk, maar niet noodzakelijk;
- C – could haves: wat aan bod komt als er tijd genoeg is;
- W – won’t haves: wat in een volgende iteratie of project aan bod komt.
Zoals de ontwikkelaar van een auto dat ook doet en afweegt of hij bijvoorbeeld een motor met 4- of 6- cilinders zou willen. Vanzelfsprekend is de MVP – het minimum viable product – eentje waar zoveel mogelijk Stories inzitten met de noemer ‘noodzaak’ en zo min mogelijk met de noemer ‘mogelijk’ – de 4-cilinder motor, dus.
Om een gebruiker van de Appie-app te laten zien of er een winkel in de buurt is, is het niet per se nodig om veel informatie over de winkel te geven. Een MVP van deze functionaliteit focust dan ook op het opvragen van de locatie van de gebruiker, een kaart/Maps-omgeving laden en het weergeven van winkels die in de buurt zijn.
Conclusie
Zoals je hierboven leest, is Story Mapping een methode die het gemakkelijker maakt om inzicht te krijgen in het ontwikkelingsproces. De workflow van de ontwikkeling is hierdoor voor meer dan slechts de Product Owner duidelijk. Dit voorkomt dat je een product lanceert dat niet aan de wensen van de gebruiker voldoet, omdat er niet vanuit het perspectief van de klant of gebruiker gedacht is.
Ook is de kans kleiner dat het (software-)product niet goed functioneert, doordat bepaalde Stories niet op elkaar aansluiten. Hierdoor is Story Mapping – in de woorden bedenker Jeff Patton – geen hype, maar eerder een patroon of gebruik geworden. Het maakt het ook makkelijker om tot een MVP te komen en sneller vanuit iteraties te werken.
Over MVP lees je meer in deze blog.
Dit blog verduidelijkt hopelijk wat Story Mapping is en verklaart waarom het meer is dan een hype. Wil je meer weten over Story Mapping – of hoe wij Story Mapping toepassen in ons proces? Neem dan contact met ons op.
