User stories: uitleg, voorbeelden en voordelen

In het grootste deel van de agile of hybride projecten worden de requirements  met behulp van user stories opgesteld. Het is dan ook de aanbevolen requirements­techniek voor agile omgeving.

Dit moet je weten als je in een agile omgeving werkt en de user story-techniek ten volle wilt benutten:

Wat zijn user stories?

User stories representeren requirements verteld vanuit het gezichtspunt van de gebruikers. User stories geven de toegevoegde waarde en de behoeften van de gebruikers weer. Ze zijn in de terminologie van de business geformuleerd.template user stories

Een user story wordt in een korte eenvoudige zin weergegeven. Bij voorkeur op de volgende manier:

Als een <type gebruiker>
wil ik <iets doen>
zodat ik <er iets aan heb>

Ter illustratie enkele voorbeelden:

  • Als boekkoper wil ik de beoordelingen van anderen zien, zodat ik de kwaliteit van het boek kan inschatten
  • Als een geregistreerde gebruiker wil ik een nieuw wachtwoord kunnen aanvragen, zodat ik toch toegang kan krijgen als ik mijn wachtwoord ben vergeten
  • Als marketingmanager wil ik de resultaten van oude advertentiecampagnes kunnen zien, zodat ik kan besluiten welke campagnes ik wil herhalen
  • Als student wil ik mijn cijfers online bekijken, zodat ik sneller weet of ik het examen heb gehaald

 

Een user story bestaat uit 3 onderdelen

Als men het over user stories heeft, wordt vaak alleen de beschrijving van een user story bedoeld. Lang niet iedereen weet dat een user story uit drie onderdelen bestaan én dat de beschrijving niet eens de belangrijkste is.  

1. Korte beschrijving

Bovenstaande voorbeelden laten slechts de korte beschrijving van de user stories zien. Het zijn reminders voor de user stories. Het is uitdrukkelijk niet de bedoeling om een user story, ofwel de gewenste functionaliteit, volledig en tot in detail te beschrijven. Het is namelijk effectiever om de detail­informatie mondeling over te dragen.

2. Mondelinge communicatie

Het tweede en belangrijkste onderdeel van een user story is de mondelinge communicatie. Het gesprek dus tussen het ontwikkelteam en de product owner (gebruiker en/of analist) over de gewenste werking van de software. Voordat een ontwikkelaar een user story kan implementeren, heeft hij allerlei detail­ informatie nodig.

De korte beschrijving dwingt hem om vragen te gaan stellen aan de product owner. Dit gebeurt tijdens de voorbereiding (in backlog refinement sessies) en tijdens de sprint zelf. De antwoorden worden, voor zover nodig om de correcte werking van de gerealiseerde software vast te stellen, vastgelegd als acceptatie­criteria.

3. Acceptatie­criteria

De acceptatie­criteria vormen het derde onderdeel van user stories. Ook de acceptatie­criteria hoeven niet volledig te zijn. (Hier vind je een uitgewerkt voorbeeld.) Tenminste als het ontwikkelteam en de product owner intensief samenwerken bij het implementeren van de user stories.

Requirements detailleren, testen en software ontwikkelen gaan dan hand in hand. De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden.

De voordelen (en beperkingen) van user stories

User stories komen uit de agile beweging voort. Ze ondersteunen derhalve perfect de agile manier van werken. Dat is tegelijkertijd ook de beperking van deze techniek. Als je niet puur agile werkt zijn niet alle voordelen van toepassing en kunnen ze zelfs omslaan in nadelen. In traditionele en sommige hybride omgevingen raad ik user stories dan ook af.

De voordelen van user stories in agile omgevingen:

Ze stimuleren mondelinge communicatie

Omdat beschrijvingen van user stories geen gedetailleerde ­informatie bevatten, ontkomt het ontwikkelteam niet aan het stellen van vragen aan de product owner.

Het is eenvoudiger dan traditionele requirements

Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want we weten ondertussen dat het onmogelijk is om de requirements volledig en eenduidig te specificeren.

Het kost minder tijd 

Mondelinge communicatie tussen het ontwikkelteam en de product owner kost minder tijd dan:

  • het specificeren van alle gedetailleerde requirements door een analist
  • het lezen en begrijpen van die specificaties door de ontwikkelaars en testers
  • het doorvoeren van wijzigingen in de specificaties

Je kunt beter omgaan met voortschrijdend inzicht

Doordat je een user story pas kort voor de sprint uitwerkt, creëer je maximale ruimte voor voortschrijdend inzicht. Tot aan de start van de sprint waarin de story geïmplementeerd wordt, heeft voortschrijdend inzicht nauwelijks een negatief effect op het project.

Ze hebben de juiste omvang

In verband met het plannen van sprints moeten user stories in maximaal een halve sprint geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, kunnen eenvoudig opgesplitst worden.

Ze bevorderen de samenwerking

Met user stories wordt het mogelijk om de brugfunctie (van de analist) tussen de business en IT, te vervangen door een nauwe samenwerking van het ontwikkelteam en de product owner. 

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap