Wat een goede user story onderscheidt van een slechte, met concrete voorbeelden
De user story is een gangbare manier geworden om een behoefte in een digitaal project te beschrijven. De eenvoudige vorm, "als, wil ik, zodat", verbergt echter een echte moeilijkheid. Een user story kan perfect aan die structuur beantwoorden en toch een groot deel van de behoefte onduidelijk laten. De vragen komen dan tijdens de ontwikkeling, wanneer beslissingen duurder worden om aan te passen.
Een voorbeeld van een slechte user story
"Als gebruiker wil ik mijn bestellingen zien, zodat ik mijn aankopen kan opvolgen."
Deze formulering lijkt correct, maar zegt bijna niets bruikbaars. Wie is "de gebruiker": een eindklant, een medewerker van de klantendienst of een accountbeheerder? Wat betekent "mijn bestellingen zien": een eenvoudige lijst, een gedetailleerde status of een volledige historiek? Over welke periode? Wat gebeurt er als er geen bestellingen zijn, als een bestelling geannuleerd werd of als bepaalde informatie ontbreekt?
Niets daarvan is vastgelegd. Het technische team zal dus vragen moeten stellen of zelf bepaalde beslissingen moeten nemen. Twee mensen kunnen dezelfde user story daardoor verschillend interpreteren.
Dezelfde behoefte, beter geformuleerd
"Als klant die minstens één bestelling heeft geplaatst, wil ik mijn tien meest recente bestellingen zien met hun huidige status, zodat ik weet of ik voor een van die bestellingen nog actie moet ondernemen."
Deze versie maakt duidelijk om welke rol het gaat, wat er moet worden weergegeven en waarom die informatie nuttig is. Ze beschrijft nog niet het scherm, de kleur van elementen of de gebruikte technologie. Ze geeft wel voldoende context om de oplossing te bespreken en te bepalen welke punten nog moeten worden verduidelijkt.
De user story kan vervolgens worden aangevuld met acceptatiecriteria: de bestellingen worden weergegeven van meest recent naar oudste, alleen de tien meest recente worden getoond, de status komt overeen met de huidige toestand van de bestelling en wanneer er geen bestellingen zijn, verschijnt een specifieke melding.
Het resultaat is gemakkelijker te ontwikkelen, maar vooral gemakkelijker te controleren met het business-team.
Wat een user story werkelijk bruikbaar maakt
Ze maakt duidelijk om welke rol het gaat, in plaats van een te brede categorie te gebruiken. "Gebruiker" verbergt vaak verschillende profielen met andere behoeften en rechten.
Ze beschrijft een behoefte en de bedoeling erachter. Het gedeelte "zodat" is niet louter decoratief: het maakt duidelijk waarom de vraag bestaat en helpt voorkomen dat een functionaliteit wordt gebouwd waarvan het werkelijke nut niet duidelijk is.
Ze wordt aangevuld met acceptatiecriteria. Dat zijn de concrete voorwaarden waarmee kan worden gecontroleerd of het resultaat aan de behoefte voldoet. Zonder die criteria steunt de validatie al snel op een algemene indruk of op verschillende interpretaties tussen de betrokken personen.
Ze houdt rekening met relevante randgevallen. Wat gebeurt er als de lijst leeg is, als data ontbreekt of als de actie mislukt? Niet elk denkbaar scenario hoeft te worden gedocumenteerd, maar situaties die het verwachte gedrag kunnen veranderen, moeten worden geïdentificeerd.
Tot slot blijft ze gericht op de behoefte en niet op de interface. "Ik wil een rode knop rechtsboven" beschrijft al een oplossing. De behoefte kan bijvoorbeeld zijn: "Ik wil mijn aanvraag kunnen annuleren voordat ze wordt gevalideerd." Hoe die actie technisch en visueel wordt aangeboden, kan daarna met het product- en technische team worden besproken.
Een veelgemaakte fout om te vermijden
Te brede user stories schrijven die in werkelijkheid meerdere verschillende behoeften bevatten.
"Als beheerder wil ik bestellingen beheren" lijkt praktisch, maar verbergt waarschijnlijk meerdere acties: een bestelling raadplegen, wijzigen, annuleren, gegevens exporteren of de status aanpassen. Elke actie kan haar eigen regels, rechten en uitzonderingssituaties hebben.
Door deze behoeften op te splitsen in meerdere user stories worden ze gemakkelijker te begrijpen, te prioriteren, te ontwikkelen en te testen. Die opsplitsing mag echter niet mechanisch gebeuren: het doel is niet om zo veel mogelijk tickets te creëren, maar om elke behoefte voldoende duidelijk te maken om ze te kunnen bespreken en valideren.
Samengevat
Een goede user story herken je niet alleen aan haar vorm. Ze maakt duidelijk wie een behoefte heeft, wat die persoon probeert te bereiken en waarom, en maakt het vervolgens mogelijk om concreet te controleren of de oplossing aan die behoefte voldoet. Acceptatiecriteria en relevante randgevallen vullen de beschrijving aan waar dat nodig is. De tijd die je vooraf investeert in deze verduidelijking voorkomt vooral dat het technische team en de business verschillende beslissingen nemen over wat er precies gebouwd moest worden.
Een user story is pas bruikbaar als het hele team er hetzelfde uit kan afleiden. Als uw teams tijdens de ontwikkeling veel tijd besteden aan het verduidelijken van user stories, kan ik helpen om behoeften, acceptatiecriteria en uitzonderingen duidelijker te formuleren.