User stories zijn in korte tijd zeer populair geworden. Het is dan ook de aanbevolen requirements­techniek in agile omgeving. Tegenwoordig worden de requirements in het grootste deel van de agile of hybride projecten met behulp van user stories opgesteld.

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 en zijn in de terminologie van de business geformuleerd.

User story template

User stories worden in korte eenvoudige zinnen beschreven bij voorkeur op de volgende manier:

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

Ter illustratie enkele voorbeelden van user stories:

  • 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

De 3 onderdelen waaruit een user story bestaat

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 de user stories ofwel de 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 user stories is de mondelinge communicatie, het gesprek tussen het ontwikkelteam en de product owner (gebruiker en/of analist) over de gewenste werking van de user stories. Voordat een ontwikkelaar een user story kan implementeren, heeft hij allerlei detail­informatie nodig. User stories dwingen 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, 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 en 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 voor agile omgevingen:

  • User stories stimuleren mondelinge communicatie
    Omdat beschrijvingen van user stories geen detail­informatie bevatten, ontkomt het ontwikkelteam niet aan het stellen van vragen aan de product owner.
  • Met user stories werken is eenvoudiger
    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.
  • User stories kosten 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
  • User stories kunnen beter omgaan met voort­schrijdend inzicht
    Doordat je een user story pas kort voor de sprint uitwerkt, creëer je maximale ruimte voor voort­schrijdend inzicht. Tot aan de start van de iteratie/sprint waarin de user story geïmple­men­teerd wordt, heeft voort­schrijdend inzicht dan nauwelijks een negatief effect op het project.
  • User stories hebben de juiste omvang
    In verband met het plannen van sprints/iteraties moeten user stories in maximaal een halve sprint geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, kunnen eenvoudig opgesplitst worden.
  • User stories bevorderen de samenwerking
    Met user stories wordt het mogelijk om de brugfunctie (van de analist) tussen de business en de ICT, te vervangen door een nauwe samenwerking van het ontwikkelteam en de product owner.

Voor analisten die goede user stories met precies genoeg details willen opstellen, heb ik een uitgebreid online programma gemaakt over alle facetten van de user story-techniek. Kijk hier voor informatie over de masterclass Vervolmaken van je user stories.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan met anderen via de share knoppen aan de zijkant.

Gratis preview Handboek Requirements

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek

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

# abonnees

Abonneer je en ontvang eens per maand een nieuw artikel