User stories

Heb je weleens overwogen om user stories te gebruiken bij het achterhalen van de requirements? Het is de aanbevolen requirementstechniek in een agile omgeving. Aangezien steeds meer organisaties overstappen op agile softwareontwikkeling winnen user stories aan populariteit.

Dit moet je weten als je besluit om met user stories te starten:

Wat zijn user stories?

User stories representeren requirements verteld vanuit het gezichtspunt van de gebruikers. User stories geven de business values en de behoeften van de gebruikers weer en zijn in de terminologie van de business geformuleerd.

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>.

Voorbeelden van user stories

Ter illustratie enkele voorbeelden van user stories.

• Als boekkoper wil ik de klantbeoordelingen van een boek lezen zodat ik beter kan beslissen of ik het boek wil kopen.
• Als een geregistreerde gebruiker, wil ik een nieuw wachtwoord kunnen aanvragen zodat ik weer toegang kan krijgen als ik mijn wachtwoord vergeten ben.
• 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 onderdelen waaruit user stories zijn samengesteld

Bovenstaande voorbeelden van user stories laten slechts de korte beschrijving zien waarmee de user stories worden aangeduid. 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 detailinformatie mondeling over te dragen.

Het tweede en belangrijkste onderdeel van user stories is dan ook de mondeling communicatie, het gesprek tussen het ontwikkelteam en de product owner (gebruiker) over de gewenste werking van de user stories. Als een ontwikkelaar een user story gaat implementeren, heeft hij allerlei detailinformatie nodig. User stories dwingen hem om vragen te gaan stellen aan de product owner. De product owner moet (bij voorkeur continue) beschikbaar zijn voor het beantwoorden van deze vragen. Voor zover nodig om de correcte werking van de gerealiseerde software vast te stellen, worden de antwoorden vastgelegd als acceptatiecriteria.

De acceptatiecriteria vormen het derde onderdeel van user stories. Ook die acceptatiecriteria hoeven niet volledig te zijn. Het ontwikkelteam en de product owner werken immers intensief samen bij het implementeren van de user stories. Requirements detailleren, testen en software ontwikkelen gaan 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. Aangezien een user stories in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren.

Samenvattend bestaan user stories uit drie onderdelen:

• een korte beschrijving als aanduiding van de requirement (ivm planning)
• mondelinge communicatie om de details te achterhalen (tijdens de realisatie)
• acceptatiecriteria om juiste werking vast te stellen

De voordelen van user stories boven use cases

Het is niet verwonderlijk dat in een agile omgeving, user stories duidelijke voordelen hebben boven use cases. Use cases zijn aan het eind van de vorige eeuw geïntroduceerd toen we nog alles uit de kast trokken om de requirements zo volledig en eenduidig mogelijk te specificeren. User stories komen daarentegen uit de agile beweging voort.

De voordelen van user stories boven use cases zijn:

• User stories bevorderen de samenwerking
  In plaats van analisten een brugfunctie laten vervullen tussen de business en de ICT, werkt het hele ontwikkelteam samen met de product owner om de user stories te detailleren.
• User stories stimuleren mondelinge communicatie
  Omdat beschrijvingen van user stories geen detailinformatie bevatten, ontkomt het ontwikkelteam bijna 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 het is onmogelijk om de requirements (in use cases) voor 100% 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 voortschrijdend inzicht
  De verschuiving van up front naar just in time requirements, zoals bij user stories het geval is, geeft maximale ruimte voor voortschrijdend inzicht. Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project.
• User stories hebben de juiste omvang
  In verband met het plannen van iteraties/sprints moeten user stories in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, kunnen eenvoudig opgesplitst worden.
  Use cases daarentegen omvatten hele scenario's inclusief de uitzonderingen die nodig zijn om een op zichzelf staand waardevol resultaat te leveren aan de gebruikers. Het is zelden mogelijk om een hele use case in 10 dagen te implementeren.