Een efficiënter team met goede user stories

1️⃣Het scrum proces 

Het is niet de bedoeling van deze blog om het scrum proces helemaal toe te lichten of te doorlopen (zie voor de officiële scrum guide: https://scrumguides.org/scrum-guide.html). Ik ga ervan uit dat de basisprincipes bekend zijn. In deze blog leg ik de focus op 4 handvaten die het scrum proces biedt om:  

A. het proces en het team te optimaliseren (retrospectives)
B. een beter beeld te hebben hoeveel werk er verzet is in de afgelopen sprint (o.b.v. story points die tijdens refinements toegekend zijn)
C. een beter beeld te hebben hoeveel er in een komende sprint gedaan kan worden (sprint planning)
D. transparantie en communicatie naar stakeholders (reviews) 

Alle 4 deze onderdelen zijn van belang om het proces goed te laten verlopen en als team te kunnen verbeteren. 

2️⃣Scrum & user stories 

Hoewel ik bij alle projecten waarbij ik volgens scrum gewerkt heb met user stories gewerkt heb, zegt de officiële scrum guide hier niets over. Volgens de scrum guide gaat het over werk dat op een backlog staat en niet hoe dit werk beschreven is. User stories zijn enkel een manier om dit werk te beschrijven. Wat mij betreft is dit ook een prima manier om dat te doen. De volgende vraag die dan opkomt is wie er verantwoordelijk is voor het schrijven van de user stories. De scrum guide geeft aan dat de product owner verantwoordelijk is voor het creëren en duidelijk communiceren van product backlog items (dit kunnen dus de user stories zijn). Vervolgens is het team verantwoordelijk om deze tijdens refinements verder te verduidelijken en eventueel op te splitsen. 

3️⃣ Wat is een goede user story en waarom is dit belangrijk? 

De definitie van een goede user story is zonder concreet voorbeeld wat abstract. Het belangrijkste is dat het volledige team goed begrijpt wat er waarom moet gebeuren (initieel beschreven door de product owner) en dat in ieder geval de developers na een refinement weten hoe het gebouwd gaat worden. Voor het begrijpen van de hoe zijn de developers dus ook zelf verantwoordelijk. De vorm waarin een user story wordt beschreven is van minder groot belang zolang het volledige team de wat en waarom begrijpt. Vandaar dat user stories vaak in de volgende vorm beschreven worden. 

ALS <stakeholder>
WIL IK <de wens>
ZODAT <de waarom> 

Wanneer de bovenstaande vorm gebruikt wordt wordt de schrijver van de user story gedwongen om in ieder geval die wat en waarom te noteren. Na een refinement kan het team zorgen dat ook de hoe verder duidelijk wordt. Dat de wat en waarom duidelijk zijn is van groot belang want wanneer dit niet helder is voor het team heeft dit invloed op het volledige scrum proces: 

1. tijdens refinements ontstaan lange discussies over het wat en waarom
   Gevolg: Vergadering duurt lang en mensen verliezen hun focus
    
2. tijdens refinements ontstaan discussies over het hoe die de discussie over het wat doorkruisen
   Gevolg: dit is veelal verspilde tijd omdat het wat eerst duidelijk moet zijn voordat er over het hoe gepraat kan worden. Er worden oplossingen bedacht die later niet nodig blijken en daardoor ruis geven in de gesprekken. Ook minder technische mensen haken sneller af omdat de wat en waarom naar de achtergrond verdwijnen
   
3. de hoeveelheid werk voor een user story wordt verkeerd ingeschat
   Gevolg: tijdens de sprint komt meer of ander werk naar boven. Hierdoor komt werk niet af en worden sprint doelen niet gehaald. 
4. het blijft onduidelijk hoeveel werk er in de komende sprint opgepakt kan worden
   Gevolg: dit zorgt voor discussies met de business tijdens sprint reviews en schaad het imago van het team. Je bent onvoorspelbaar en dit zal niet verbeteren zolang user stories niet goed ingeschat kunnen worden.

De bovenstaande zaken verstoren allemaal het scrum proces (en dan m.n. de 4 eerdergenoemde punten A, B, C en D) en zijn vaak lastig op te lossen wanneer user stories van onvoldoende niveau blijven omdat: 

Punt A: Retrospectives gaan vaak over allemaal randzaken die veelal een gevolg zijn van de ondermaatse user stories. Natuurlijk kan een goede scrum master of agile coach dit proberen in de hand te houden maar dit is lastiger wanneer user stories tot veel vragen en discussies leiden. 

Punt B: Er is een slecht beeld van het werk dat verzet is tijdens de sprint review. Bij user stories bleek de wat anders en de inschattingen klopten daardoor niet. 

Punt C: Het is moeilijk in te schatten hoeveel werk er verzet gaat worden in de komende sprint.  Ook dit komt weer doordat de user stories slecht in te schatten zijn. Hierdoor is moeilijk lering te trekken uit user stories die in eerdere sprints gerealiseerd zijn. Daarnaast zorgt het voor onvoorspelbaarheid terwijl de opdrachtgever juist graat voorspelbaarheid wil hebben. 

Punt D: Tijdens de reviews zal het team vaker moeten aangeven dat zaken niet af zijn of feedback krijgen dat men andere verwachtingen had. Dit is natuurlijk ook het doel van een review, maar het is een prettigere boodschap wanneer je kan vertellen dat zaken af zijn en dat ook blijkt dat het naar verwachting van de opdrachtgevers is.  

4️⃣ Hoe krijg ik betere user stories voor mijn team 

Wanneer bovenstaande punten herkenbaar zijn en op jouw project spelen is de eerst stap om het hier als team overeens te worden. Zodra je dit als team onderkend zie ik 3 belangrijke actiepunten: 

1. De product owner dient ondersteuning te krijgen om user stories van meer detail te voorzien voordat ze verder in het team besproken worden (hier kan elk teamlid of iemand vanuit de business bij helpen) 
2. Het team als geheel moet kritisch zijn en user stories pas in de sprint opnemen wanneer ze voldoende duidelijk zijn. Dit kan soms vervelend aanvoelen maar uiteindelijk help je het team en de opdrachtgever hiermee. Probeer dit ook altijd op een constructieve manier te doen door ook te helpen de user stories te verbeteren. 
3. Ga gebruik maken van een template voor de user stories. Dit zorgt ervoor dat user stories altijd op eenzelfde manier worden beschreven en dat de wat, waarom en uiteindelijk ook de hoe niet vergeten kunnen worden 

5️⃣User story template 

Een veelgebruikte template voor het globaal beschrijven van de user story is eerder al langsgekomen (Als, wil ik, omdat). Om de user story vervolgens verder te verduidelijken is er meer nodig. Een goede vorm hiervoor die ik regelmatig gezien heb is als volgt. 

Template 

ALS <stakeholder>
WIL IK <de wens>
ZODAT <de waarom> 

Acceptatiecriteria
– ….
– …. 

Technische punten:
– ….
– …. 

Voorbeeld van een user story bij een webwinkel 

ALS productbeheerder
WIL IK nieuwe producten van onze leveranciers kunnen goedkeuren voor verkoop in de webshop
ZODAT de leverancier zijn/haar producten zo snel mogelijk via onze webshop kan verkopen 

Acceptatiecriteria
– Het productbeheerscherm wordt uitgebreid met een tabblad “Nieuwe producten”
– Op het tabblad staat een overzicht van alle nog niet beoordeelde producten van onze leveranciers
– Bij elk product staat een knop goedkeuren en een knop afkeuren
– Na het klikken op goedkeuren zal het product direct goedgekeurd worden en beschikbaar zijn in de webshop
– Na het klikken op afkeuren wordt het product afgekeurd en is het niet beschikbaar in de webshop
– Zie schermontwerpen in de bijlage  

Technische punten:
– Voor het ophalen van de niet beoordeelde producten kunnen de bestaande operaties op de ProductService gebruikt worden
– Het goedkeuren of afkeuren van de producten gebeurt ook via de ProductService. Alle logica om het product wel/niet beschikbaar te maken in de webshop is hierin al geïmplementeerd. 

Wanneer het bovenstaande template gebruikt wordt zullen stories altijd dezelfde structuur hebben en het dwingt de product owner en het team om altijd over het wat, waarom en hoe na te denken. Het gegeven voorbeeld van de webwinkel is ter verduidelijking en zou uiteraard nog verder uitgebreid kunnen worden. 

⏩Conclusie 

In deze blog heb ik geprobeerd aan te geven dat het fundamenteel is voor een goed scrum proces dat het werk op de backlog (vaak user stories) voldoende duidelijk is. Wanneer dit niet het geval is verstoord dit het gehele scrum proces en is het ook moeilijk om zaken te verbeteren. Mijn belangrijkste advies is dan ook om de user stories op een voldoende niveau te krijgen zodat het gehele team begrijpt wat er moet gebeuren en waarom. De product owner is hier verantwoordelijk voor maar het hele team dient hier indien nodig een bijdrage aan te leveren. Pas wanneer dit op orde is kunnen refinements soepeler gaan lopen en kan er een beter beeld komen hoeveel werk een team verzet en de komende sprint kan gaan verzetten. Het template dat ik gegeven heb kan helpen om user stories naar een beter niveau te brengen. 

Heb je over deze blog een mening of feedback aarzel dan niet om contact op te nemen!