User stories maken: tijdrovend of tijd- en kostenbesparend?

User stories overslaan als je middenin een sprint zit en het tempo hoog is: verleidelijk, zeker als je veel voorbereiding hebt gestoken in het hoogover plaatje. Je weet namelijk precies aan welke doelstelling jouw komende release bijdraagt en welke functionaliteiten daar bij horen. Wil je echt de garantie dat je het gewenste IT-resultaat bereikt, dan zit the devil (of garantie) wat mij betreft opnieuw in the details.  

Het visualiseren van de releaseketen is weliswaar een uitstekende manier om het grote geheel te begrijpen, toch loop je het risico om de specifieke behoeften van de gebruikers te missen. Want wat nou als de focus teveel op technische aspecten van de release ligt in plaats van op gebruikerservaring? Het antwoord is een product dat niet 100 procent aansluit op de wensen van de business, wat kan leiden tot ontevredenheid en frustratie.  

Het definiëren en valideren van user stories helpt de complete keten om de functionaliteit te begrijpen die nodig is om de gebruikersbehoeften te ondersteunen. Dat maakt jouw grotere plaatje, als het goed is, af. Je verbetert de communicatie tussen de verschillende stakeholders en het team, waardoor er minder interpretatieverschillen ontstaan. Hoe minder onduidelijkheid en misverstanden, hoe sneller je kunt releasen met behoud van kwaliteit.  Dat is, denk ik, cruciaal. Zeker als je weet dat een ketenrelease een manier is om samenwerking en communicatie tussen verschillende teams te verbeteren. Het gebruik van user stories heeft naderhand nog een extra voordeel: je kunt beter meten of je jouw doelstellingen daadwerkelijk hebt behaald.  

Het is belangrijk dat je user stories schrijft vanuit het perspectief van de beoogde waarde, zodat het sprintteam zich kan concentreren op het leveren van de gewenste functionaliteit aan de gebruikers. Denk aan een key user binnen jouw organisatie of je klant. Dit schrijven en valideren gebeurt meestal in de voorbereidingsfase van een IT-release, wanneer de vereisten en doelstellingen van het project duidelijk zijn gedefinieerd. In user stories borg je bijvoorbeeld wie de eindgebruiker(s) is, welke actie de gebruiker wil uitvoeren en wat het resultaat daarvan moet zijn. 

Identificeer de belangrijkste gebruikers en verzamel hun eisen en wensen. Dit helpt je om beter te begrijpen welke functies en functionaliteiten belangrijk zijn en hoeveel user stories er nodig zijn om deze te implementeren. Prioriteer de user stories op basis van de waarde die ze bieden. Dit helpt je ook om in te schatten hoeveel user stories je per sprint kunt afronden.  

Een user story hoeft niet lang te zijn. Sterker nog: een user story moet klein genoeg zijn om binnen één sprint af te kunnen ronden. Als je het volgende template invult, kom je al heel ver: Als <key user> wil ik het volgende kunnen <actie/deliverable> zodat <impact>. Een goed voorbeeld is: .......... In ons artikel over de randvoorwaarden voor een goede user story lees je wat een user story een goede user story maakt.  

Besef je verder dat je niet voor niks een ketenrelease doet. Mijn tip is daarom om user stories altijd met meerdere stakeholders te schrijven. Iedereen kan vanuit zijn rol en expertise een unieke bijdrage leveren aan het definiëren van de functionaliteit van het product en de behoeften van de gebruikers. De product owner heeft bijvoorbeeld kennis van de markt en de klantbehoeften, terwijl ontwikkelaars technische expertise hebben en de haalbaarheid van bepaalde functies kunnen beoordelen. Testers kunnen je helpen bij het identificeren van mogelijke problemen en het verbeteren van de gebruikerservaring. En de klant of eindgebruikers kunnen hun ervaringen delen en feedback geven over wat voor hen belangrijk is in het product. Mooi meegenomen: het gezamenlijk opstellen van user stories draagt meteen bij aan een betere samenwerking tussen de verschillende stakeholders en leidt tot meer begrip voor elkaars perspectieven.  

Ik kan mij goed voorstellen dat schrijven makkelijker is dan doen. Dit gaat zeker op als jouw organisatie gewend is om bestaande processen te volgen of als het tempo vanwege de ontwikkelingen in jouw markt hoog is. Hoe je user stories op een consistente en goede manier opneemt in elke release, is voor elke organisatie anders. Vanuit Bolt it kijken we graag mee wat het beste werkt voor jou en de projectmanagementmethodiek die je toepast.  

Wil je de kwaliteit van jouw user stories voor de hele keten graag valideren door een externe partij, zonder meteen ergens aan vast te zitten? Stuur mij een mail op roel@boltit.nl, dan kijk ik vrijblijvend eens met je mee. 

Roel Joosten is Bolt it vanuit één overtuiging gestart: je kunt alleen excelleren, als je de beste inzichten met elkaar verbindt. Eerder werkte hij als CTO voor RNHB en als programma manager voor DLL, Rabobank en Interpolis. Hij was betrokken bij de transformatie van deze organisaties naar technologie gedreven platforms.