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 je magische hulpmiddel.
Het is een methode en een visuele tool die door Jeff Patton bedacht is. Bij het beheren van softwareontwikkelingsprojecten wordt Story Mapping gebruikt voor planning. In dit artikel zal ik vooral de voordelen voor het bedrijfsleven benadrukken en waarom je daar tijd aan zou moeten besteden met je ontwikkelteam.
Eén ding vergeten ondernemers vaak: je bent niet je ideale klant. Evenmin is je ontwikkelingsteam. Je wilt echter weten wie je ideale klant is en hoe hij zich gedraagt tijdens het gebruik van je product.
Als producteigenaar en maker wil je bepaald gedrag analyseren dat je gebruikers vertonen tijdens het gebruik van het product, wat voor soort probleem ze proberen op te lossen. Wanneer je gedrag omzet in een reeks stappen, dan plak ze op de stickers op de muur, koppel ze allemaal op de meest efficiënte en functionele manier en breng in kaart, krijg je een uitgebreide visuele kaart van het toekomstige product.
Is het geen geweldige manier om te kijken hoe een individuele gebruikersreis past bij een hele wereldwijde ervaring van je productgebruik?
Duidelijk ontworpen verhalen helpen je de gebruiker via het kortste pad naar zijn doel te leiden. Bovendien stelt Story Mapping je in staat om aannames te bouwen, nieuwe functies te testen onder verschillende gebruikerspersonages (ik zal daar later op ingaan) en allerlei experimenten te doen met mogelijke gebruikers. Terwijl je Stories bouwt en in kaart brengt, kun je functies ontwikkelen en introduceren waar je nog niet eerder aan had gedacht.
Net als je willen wij je klant begrijpen, zodat we een eindgebruikersvriendelijk product kunnen afleveren. Ons doel is om iteraties sneller en vaker te maken. Samen kunnen we een groter project opsplitsen in kleinere projecten, voor een eenvoudiger gezamenlijke aanpak en om functies op te splitsen in kleinere releases.
Dus vanuit het perspectief van ontwikkelaars krijgen we na een Story Mapping-sessie een duidelijke lijst van de User Stories, om verder te worden opgesplitst in functies voor je product. Met Story Mapping ontwerpen we software die nauwkeuriger werkt in overeenstemming met de verwachtingen en wensen van de users.
Verdere kenmerken worden opgesplitst in functies en taken en vormen de product backlog. Ik zal een paar termen gebruiken voor ons gemak verderop in het artikel om enkele van de functies in Story Mapping te beschrijven.
De functies zijn:
· Epics. Dit zijn je grote doelen en fundamentele stappen van het product.
Voorbeeld van een Epic: een beheerde mailbox.
· Stories. Dit zijn subdoelen van een groot doel (van een Epic).
Als ik doorga met het voorbeeld van het bovenstaande epos, zijn de voorbeelden van Stories het verwijderen, beantwoorden en opstellen van e-mails.
Om het bovenstaande samen te vatten, zijn er twee belangrijke voordelen van Story Mapping, die de magische synergie kunnen creëren tijdens het ontwikkelen van een product:
- Je begrijpt je klantreis beter, waardoor je product meer kansen krijgt om op de markt te slagen
- Het ontwikkelingsproces verloopt soepel, iteratief en vermijdt tijd- en kostenverspilling
Gezien het bovenstaande is Story Mapping in Agile voor mij een zeer effectieve methode in het algemeen, en vooral voor een MVP die ik wat later zal beschrijven.
Voorbeeld van het echte leven:
Nu zal ik stap voor stap uitleggen hoe Story Mapping precies werkt en om het eenvoudig te lezen, zal ik als voorbeeld een product gebruiken waaraan we met succes hebben gewerkt: Support Points. Het is een online digitaal platform dat klanten van productie verbindt met PLC (Programmable Logic Controllers) problemen met experts die slecht functionerende PLC’s en softwaremodificaties ondersteunen.
Stap 1: Bepaal het concept, de vraag en de vraag achter de vraag.
Het maakt niet uit of we een app, een one-pager website of een ander type product ontwikkelen, het is heel gebruikelijk om het doel dat je probeert te bereiken te verwarren met de tool die je probeert te maken. Alleen maar op de tool te concentreren is niet de oplossing.
Om deze verwarring te voorkomen, zou ik aanraden om twee kernvragen te stellen:
Welk probleem probeer je op te lossen? (dit is de vraag)
en dan…
Waarom moet je het oplossen? (dit is de vraag die achter de vraag staat).
Met SupportPoints is het probleem dat we proberen op te lossen de machinebediende 24/7 toegang te geven tot directe PLC-ondersteuning in geval van uitval van apparatuur.
Waarom willen we dit doen? Omdat de operator zijn productielijn onmiddellijk moet laten draaien.
Om dit op te lossen, ontwikkelen we een uitgebreide manier om klanten te verbinden met SupportPoints. We willen ervoor zorgen dat we het duidelijk laten zien door middel van ontwerpelementen van de website, waar elk element de volgende ‘waarom’-vraag zal beantwoorden.
Stap 2: Bepaal Story Mapping persona’s (users)
Verschillende gebruikers loggen in op het systeem om verschillende bewerkingen uit te voeren. In het geval van SupportPoints zijn er enkele soorten gebruikers: de ene kan op zoek zijn naar een directe oplossing voor een technisch probleem, een andere kan op zoek zijn naar een expert op een bepaald gebied, etc. Admin, die de inhoud van het systeem beheert, of support tickets is ook een persoon om in gedachten te houden. Dit zijn voorbeelden van zogenaamde persona’s – de gewenste users van het product in uitvoering.
Ons doel is om zoveel mogelijk Story Mapping persona’s te identificeren zodat er geen type user wordt achtergelaten.
Het identificeren van user persona’s voor SupportPoints
Stap 3: Begin met de stam van de boom — Epics
Het ontwikkelen van een digitaal product begint met het definiëren van de functies, de bovengenoemde grote doelen, ook wel Epics genoemd. Het woord spreekt voor zich: het is een verhaal dat “episch” en groot is.
Een Epic helpt context en perspectief aan de Story te geven (kleinere en meer gedefinieerde doelen) en draagt bij aan hun ontwikkeling. Daarom noemen ze Epic de ruggengraat en de verhalen – de rest van het skelet.
Wat we met Epics voor SupportPoints hebben gedaan, is gedefinieerd wat SupportPoints doet en de duidelijke bewerkingen die de hierboven gedefinieerde persona’s moeten uitvoeren. Vervolgens hebben we ze op de hoofdpagina gemarkeerd, waardoor ze visueel heel duidelijk zijn.
Epics zijn oranje met hun respectievelijke verhalen die roze hieronder zijn als voorbeeld
Stap 4: Ga verder met de branches — Stories
Stories staan zowel metaforisch als fysiek onder de Epics. Ten eerste kun je een Epic opsplitsen in verschillende Stories – individuele afzonderlijke functies die het mogelijk maken om als een geheel te werken. Ten tweede worden Stories in Story Mapping zelf fysiek onder de Epics geplaatst.
Dit is een uitzonderlijk interessant proces waaraan we je aanmoedigen deel te nemen. Heel vaak eindigt een product dat je je voorstelt niet precies hetzelfde als het product dat je in gedachten had: het gedrag van gebruikerspersonages kan een weerspiegeling zijn van iteraties, veranderingen en aanpassingen.
Samen kunnen we een stap terug doen en een grote afbeelding van Epics and Stories bekijken gebaseerd op de user die centraal staat in het proces.
We gebruiken plaknotities op een witte muur en herschikken de workflow en de prioriteiten op de meest probleemloze manier.
Hier is hoe we het hebben gedaan met SupportPoints:
Op het hoogste niveau hebben we de Epics bijvoorbeeld onderverdeeld in: Hoofdpagina – Registratie – Een expert zoeken, enz. – de lijst was lang en vervolgens had elke Epic zijn verhalen hieronder.
Hoofdpagina:
· Info
· Over
· Hoe het werkt
· Enz.
Het was een muur bedekt met tientallen plaknotities die een heel goed overgewogen project werden. Zoals ik hierboven al zei, het grootste voordeel: je ziet een kaart van hoe een bepaalde persoon je product gebruikt en integreert je ideeën onderweg.
Wanneer we aan deze Story Mapping-muur werken, analyseren we waarom een gebruiker zich zo gedroeg, waarom hij een functie oversloeg of waarom hij ervoor koos langer op een bepaalde pagina te blijven. We beslissen samen of we sommige delen moeten weglaten omdat ze niet worden aangeraakt door alle personagegroepen van de gebruiker. Mogelijk krijg je een nieuwe visie als je ziet hoe een gebruiker op een functie reageert.
Hierdoor plannen we samen het project, plannen we het beter en blijft er geen partij achter, zitten we hier hand in hand en weet je als producteigenaar precies wat er met je product gebeurt en wordt het in kaart gebracht op de best mogelijke manier.
Voorbeeld van Story Mapping in de loop van de ontwikkeling van het project
Stap 5: Stel de prioriteiten
Hoe aantrekkelijk Story Mapping ook is, je moet ergens en ergens op de juiste plaats beginnen. Hier ben ik het eens met de uitvinder van Story Mapping, Jeff Patton, die het onzin vindt om van bepaalde Epics een prioriteit te maken.
Denk aan het bouwen van een auto waarbij je ook geen onderscheid maakt tussen het maken van een motor of een rem. In Epics doet alles er toe.
Op het niveau van Stories raad ik je ten zeerste aan om prioriteiten te stellen. Ik ben een groot voorstander van de MoSCoW-methode, waarbij je je verhalen op vier niveaus van urgentie rangschikt:
M: Must haves. Absoluut nodig
S: Should haves: Wenselijk maar niet essentieel
C: Could haves: Komt aan bod als er voldoende tijd over is
W: Won’t haves. Niet gepland in de huidige iteratie of project, maar kan worden besproken voor de volgende.
Dit is hoe we ons proces hebben afgerond en de eerste prioriteiten hebben opgesteld:
Voorbeeld van eerste prioriteiten in Story Mapping
Dus, waarom dan Story Mapping?
Zoals ik heb uitgelegd, maakt Story Mapping het veel gemakkelijker om inzicht te krijgen in het ontwikkelproces. Sterker nog, het proces wordt niet alleen duidelijker voor de Product Owner, maar voor het hele team. Het is gemakkelijker om fouten in het proces te corrigeren en aan te passen aan de wensen van de gebruiker. Met Story Mapping is de kans veel groter dat je een product lanceert dat voldoet aan de verwachtingen en behoeften van de gebruikers. Uiteindelijk helpt het onze klanten om duidelijk het systeem te zien van hoe het project zal worden geïmplementeerd.
Een andere bonus is dat de software die het Story Mapping-proces heeft doorlopen, minder snel defect raakt omdat bepaalde Stories geen verbinding met elkaar maken – het is sneller om met kleine iteraties te werken en die naar de MVP te brengen.
Conclusie
Voor ons is Story Mapping geen hype en geen cargocult. Het is een berekend en onderzocht patroon en praktijk die zijn efficiëntie al heeft bewezen. Deze efficiëntie wordt verdubbeld wanneer jij en wij samen aan Story Mapping werken, waardoor we een product kunnen uitbrengen dat voldoet aan de verwachtingen van je klanten.
