Userstories met voorbeelden en een sjabloon

Samenvatting: Een userstory is een informele, algemene uitleg van een softwarefunctie die is geschreven vanuit het perspectief van de eindgebruiker. Het doel is om uit te leggen hoe een softwarefunctie waarde zal bieden aan de klant.

Het is verleidelijk om te denken dat userstories eenvoudig gezegd softwaresysteemvereisten zijn. Maar dat zijn ze niet.

Een belangrijk component van agile softwareontwikkeling is dat mensen op de eerste plaats worden gezet. Een userstory plaatst eindgebruikers centraal. Deze stories gebruiken niet-technische taal om context te bieden voor het ontwikkelingsteam en hun inspanningen. Na het lezen van een userstory weet het team waarom het bouwt, wat het bouwt en welke waarde het creëert.

Userstories zijn een van de kerncomponenten van een agile programma. Ze vormen een gebruikersgericht framework voor dagelijks werk, waarmee samenwerking, creativiteit en een beter product in het algemeen worden gestimuleerd.

Een userstory is de kleinste werkeenheid in een agile framework. Het is een einddoel – dus geen functie – dat is omschreven vanuit het perspectief van de softwaregebruiker.

Een userstory is een informele, algemene uitleg van een softwarefunctie, geschreven vanuit het perspectief van de eindgebruiker of klant.

Een userstory is bedoeld om te verwoorden hoe een bepaald onderdeel de klant een bepaalde waarde zal bieden. Merk op dat 'klanten' geen externe eindgebruikers hoeven te zijn in de traditionele zin van het woord. Ze kunnen ook interne klanten of collega's binnen je organisatie zijn die afhankelijk zijn van je team.

Userstories zijn enkele zinnen in eenvoudige taal die het gewenste resultaat schetsen. Ze zijn niet gedetailleerd. Vereisten worden later toegevoegd, wanneer het team ze overeen is gekomen.

Stories passen naadloos in agile-frameworks, zoals scrum en kanban. In scrum worden userstories toegevoegd aan sprints en 'burned down' tijdens de duur van de sprint. Kanban-teams halen userstories op in hun backlog en leiden ze door hun workflow. Juist dit werk aan userstories helpt scrumteams om beter te worden in schattingen en sprintplanning, wat leidt tot nauwkeurigere prognoses en grotere wendbaarheid. Dankzij stories leren kanban-teams hoe ze work-in-progress (WIP) kunnen beheren en kunnen ze hun workflows verder verfijnen.

Userstories zijn ook de bouwstenen van grotere agile frameworks, zoals epics en initiatives. Epics zijn grote werkitems die zijn onderverdeeld in een reeks stories; en meerdere epics vormen een initiative. Deze grotere structuren zorgen ervoor dat het dagelijkse werk van het ontwikkelingsteam bijdraagt aan de organisatorische doelen die zijn ingebouwd in epics en initiatives.

Meer informatie over epics en initiatieven

Voor ontwikkelingsteams die agile nog maar net gebruiken, lijken userstories soms een extra stap. Waarom breek je het grote project (de epic) niet gewoon op in een reeks stappen en ga je aan de slag? Maar stories geven het team een belangrijke context en associëren taken met de waarde die deze met zich meebrengen.

Userstories hebben een aantal belangrijke voordelen:

• Stories zorgen ervoor dat de nadruk op de gebruiker blijft liggen. Een takenlijst zorgt ervoor dat het team gefocust blijft op taken die moeten worden gecontroleerd, maar een verzameling stories zorgt ervoor dat het team gericht blijft op het oplossen van problemen voor echte gebruikers.
  
• Stories maken samenwerking mogelijk. Als het einddoel is vastgesteld, kan het team samenwerken om te beslissen hoe de gebruiker het beste kan worden bediend en het doel kan worden gerealiseerd;
  
• Stories stimuleren creatieve oplossingen. Stories moedigen het team aan om kritisch en creatief na te denken over hoe ze het beste oplossingen kunnen vinden om het einddoel te behalen;
  
• Stories zorgen voor momentum. Elke story levert het ontwikkelingsteam een kleine uitdaging en een kleine overwinning op, waardoor het momentum wordt gestimuleerd.

Bekijk hoe userstory's werken in Jira

Zodra een story is geschreven, is het tijd om deze in je workflow te integreren. Over het algemeen wordt een story geschreven door de producteigenaar, productmanager of programmamanager en ter beoordeling ingediend.

Tijdens een sprint- of iteratieplanningsbijeenkomst beslist het team welke stories ze tijdens die sprint zullen aanpakken. Teams bespreken vervolgens de vereisten en functionaliteit van elke userstory. Dit is een kans om technisch en creatief te zijn in de implementatie van de story door het team. Als er eenmaal afspraken zijn gemaakt, worden deze vereisten toegevoegd aan de story.

Een andere veel voorkomende stap tijdens deze vergadering is het beoordelen van de stories op basis van hun complexiteit of tijd tot voltooiing. Teams gebruiken T-shirtmaten, de Fibonacci-reeks, of planpoker om de juiste schattingen te maken. Een story moet in één sprint kunnen worden voltooid. Daarom zorgt het team tijdens het specificeren van elke story dat stories die deze voltooiingshorizon overschrijden, worden opgesplitst.

Houd rekening met het volgende bij het schrijven van userstories:

• Definitie van 'gedaan' – De story is over het algemeen 'klaar' wanneer de gebruiker de geschetste taak kan voltooien, maar zorg ervoor dat je die taak dan wel definieert;
  
• Overzicht van subtaken of taken — Bepaal welke specifieke stappen moeten worden voltooid en wie verantwoordelijk is voor elk van deze stappen;
  
• Gebruikerspersona's — Voor wie? Overweeg om meerdere stories te maken als er meerdere eindgebruikers zijn.
  
• Geordende stappen — Schrijf een story voor elke stap in een groter proces;
  
• Luister naar feedback — Praat met je gebruikers en leg het probleem of de behoefte vast in hun woorden. Je hoeft niet te raden naar stories wanneer je ze kunt ophalen bij je klanten;
  
• Tijd — Tijd is een gevoelig onderwerp. Veel ontwikkelingsteams vermijden discussies over tijd, maar vertrouwen op hun frameworks voor schattingen. Omdat stories in één sprint moeten kunnen worden voltooid, dienen stories die weken of maanden in beslag kunnen nemen te worden opgesplitst in kleinere stories of als eigen epic te worden beschouwd.
  

Zodra de userstories duidelijk zijn gedefinieerd, moet je ervoor zorgen dat ze zichtbaar zijn voor het hele team.

Userstories worden vaak uitgedrukt in een eenvoudige zin die als volgt is gestructureerd:

'Als een [persona], [wil] ik, [zodat].'

Om hier dieper op in te gaan:

• 'Als een [persona]': Voor wie bouwen we dit? We zijn niet slechts op zoek naar een functietitel, maar naar de persona van de persoon. Max. Ons team zou het erover eens moeten zijn wie Max is. We hebben hopelijk genoeg 'Maxen' geïnterviewd. We begrijpen hoe hij werkt, hoe hij denkt en wat hij voelt. We hebben gevoel voor Max;
• 'Wil': Hier beschrijven we de intentie — niet de functies die ze gebruiken. Wat willen ze eigenlijk bereiken? Deze beschrijving moet implementatievrij zijn: als je een deel van de gebruikersinterface beschrijft en niet het gebruikersdoel, mis je het punt.
• 'Zodat': Hoe past het onmiddellijke verlangen om dit te doen in het grotere plaatje? Naar welk algemene voordeel streven ze? Wat is het grote probleem dat moet worden opgelost?

Userstories kunnen er bijvoorbeeld als volgt uitzien:

• Als Max wil ik mijn vrienden uitnodigen, zodat we samen van deze service kunnen genieten;
• Als Sascha wil ik mijn werk organiseren, zodat ik meer controle heb;
• Als manager wil ik de vooruitgang van mijn collega's begrijpen, zodat ik ons succes en onze mislukkingen beter kan melden.

Deze structuur is niet vereist, maar het is nuttig om te definiëren hoe het eindresultaat eruitziet. Wanneer de persona de gewenste waarde kan realiseren, is de story compleet. We moedigen teams aan om hun eigen structuur te definiëren en zich er vervolgens aan te houden.

Userstories beschrijven het waarom en wat achter het dagelijkse werk van ontwikkelingsteams, vaak in de vorm van persona + behoefte + doel. Inzicht in hun rol als bron van waarheid voor wat je team levert, maar ook in het waarom, is de sleutel tot een soepel proces.

Begin met het evalueren van het volgende, of meest dringende, grote project (bijv. een epic). Verdeel het in kleinere userstories en werk samen met het ontwikkelingsteam aan verfijning ervan. Zodra je stories zijn gepubliceerd en het hele team ze kan zien, ben je klaar om aan de slag te gaan.