Komen tot een User Story Map
Voor een recept om te komen tot een User Story Map hebben we een aantal ingrediënten nodig:
- Een methode om functionele eisen te vinden: Domain Storytelling
- Een methode om requirements op te schrijven: User Stories
- Een methode om requirements te organiseren: User Story Mapping
Voor het gemak nemen we aan dat een team werkt aan de ondersteuning van een bedrijfsproces binnen een begrensde context. Verder gaan we ervan uit dat het team toegang heeft tot domeinexperts. In zo'n situatie is onderstaand stappenplan goed bruikbaar.
- Het team modelleert het bedrijfsproces als een medium-grained tot fine-grained DS (domain story), te beginnen met het belangrijkste scenario (meestal het happy path). Pure en gedigitaliseerde to-be domain stories werken allebei.
- Vraag jezelf voor elke activiteit in de domain story af of deze ondersteund moet worden door het nieuwe software systeem. Als vuistregel geldt: als een activiteit moet worden ondersteund door IT, schrijf er dan een requirement op kite-level voor op. Deze requirements vormen gezamenlijk de backbone van het verhaal (user journey). Deze requirements worden de backbone van je backlog in de vorm van high-level user stories (activiteiten en taken).
- Modelleer alternatieve scenario's en, indien nodig, stel meer verfijnde DS op. Verzamel informatie over uitzonderingen, mogelijke fouten, edge cases, enzovoort als annotaties in de DS.
- Loop door de nieuwe DS en de bijbehorende annotaties. Nogmaals, schrijf voor elke nieuwe zin één vereiste als user story op kite- of sea-level. Controleer je annotaties en zie welke annotaties een vereiste moeten worden en schrijf ze ook op als user story.
- Organiseer de requirements door de fine-grained requirements als user stories in kaart te brengen op de backbone binnen de ribs van een activity->taak, en creëer zo een USM (User Story Map).
Het team heeft nu een gestructureerde backlog van kite- en sea-level requirements. De backlog zal niet volledig zijn en ook niet alle requirements zijn direct klaar voor implementatie (definition of ready). Maar het team heeft wel een goed begrip van de functionele eisen en hoe deze samenkomen tot een werkbaar bedrijfsproces.
Het enige dat rest is om gezamenlijk met de stakeholders/domeinexperts de user stories in releases te plaatsen die in iteraties van het product meerwaarde kunnen opleveren.
Een side-effect van een USM (user story map) is dat er meer context informatie over de (domein) stories bewaard blijft dan bij een ouderwetse 'platte backlog'.
Voorbeeld
Casus Koffieautomaat, van tekst naar user story map
Hieronder zie je een relatief klein voorbeeld voor een casus voor een Koffie automaat 'applicatie' (A) casus beschrijving
Dan komen volgens het eerder aangeleerde stappenplan achtereenvolgens de volgende zaken uit voort:
B) coarse-grained domain story en C) een scenario/user story dan een D) fine-grained domain story uitwerking (die je kunt openklappen) en dan tot slot E) een user story map
A. Casus beschrijving koffieautomaat
Op een dorstige dag komen Alex en Max elkaar tegen bij de koffie-automaat en hebben dit gesprek.
Alex: Goeiemorgen, ook een bakkie halen?
Max: Zeker, niets zo lekker wakker worden als met een kopje koffie.
Alex: Weet jij dan al hoe die nieuwe automaat werkt?
Max: Ja hoor, het is heel eenvoudig. Eerst pak je een bekertje en dat zet je in de bekerhouder. Je kunt kiezen tussen koffie en heet water, maar ik kies altijd voor koffie. Daarna krijg ik de keuze of ik melk in de koffie wil, en zo ja hoeveel. Ik neem nooit melk, dus dan druk ik op OK en vult de automaat mijn bekertje.
Alex: En suiker dan?
Max: Oh, dat ligt los in een doos, dat moet je er zelf in doen.
Alex: Ik kan altijd moeilijk wakker worden. Ik zou geheid het bekertje vergeten.
Max: Geeft niets, als je toch probeert koffie of heet water te kiezen geeft de automaat aan dat er geen bekertje in staat. Als er een bekertje in staat kan je opnieuw een keuze maken en loopt je bekertje vol.
Alex: Ik neem maar heet water. Koffie heb ik nooit lekker gevonden.
Max: Nou, bekertje pakken, heet water kiezen en je bekertje loopt vol! Daarna kan je zelf uit een doos een theezakje pakken en suiker als je wilt.
Alex: Ha, lekker. Wie zorgt trouwens voor nieuwe koffie?
Max: Dat doet Ria van de onderhoudsdienst. Er is een aparte knop op de automaat om de voorraadruimte te openen. Als je die indrukt, gaat er op de automaat een rood lampje branden en kun je de koffie bijvullen. Als je klaar bent, wordt het lampje weer groen; zit het nieuwe pak koffie echter niet goed dan blijft het lampje rood, de automaat is dan buiten werking, totdat het pak koffie goed gezet is. Meestal neemt Ria daarna zelf even een bakkie om te kijken of ze het goed heeft gedaan.
Alex: Ik snap geloof ik helemaal hoe dat ding werkt! Werk ze vandaag!
Max: Ja, jij ook!
B. Coarse grained domain story - drank halen uit automaat
C. User Story - koffie halen
Functionaliteit: Drank halen
Als een koffie drinker
Wil ik een kop koffie
Zodat ik koffie kan drinken
D. Happy path (fine grained) domain story - koffie halen
E. User story map - drank halen uit automaat
Op basis van de domain story is de volgende user story map gemaakt (zie met opmerkingen bijbehorende terminologie):
textusm code van bovenstaande user story map
user_activities: ACTIVITEITEN
user_tasks: TAKEN
user_stories: USER STORY
release1: Koffie halen
release2: Thee halen
release3: Melk toevoegen
release4: backlog
halen drank als een dorstige wil ik een beker plaatsen zodat ik drank kan ontvangen als een dorstige wil ik een beker plaatsen zodat de koffie niet wegloopt als een thee drinker wil ik een beker plaatsen onder een andere uitloop dan koffie zodat de thee niet naar koffie smaakt als een dorstige wil ik een beker plaatsen zodat ik drank kan ontvangen als een koffie drinker wil ik een kop koffie zodat ik koffie kan drinken als een thee drinker wil ik een kop thee zodat ik thee kan drinken als een koffie drinker wil ik melk in mijn koffie zodat ik koffie met melk kan drinken als een koffie drinker wil ik een kop cappucino zodat ik een fatsoenlijk bereidde cappucino kan drinken