Binnen de agile softwareontwikkeling vormen de zgn. user stories de aanbevolen requirementstechniek. User stories staan voor requirements verteld vanuit het gezichtspunt van de gebruikers. Belangrijk hierbij is dat de veranderbehoefte wordt weergegeven in de taal van taal van de business.

Volgens Nicode de Swart voldoen user stories bij voorkeur aan de syntax: "Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>" en geeft hierbij als voorbeeld: "Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald." Het gaat hierbij alleen om de korte omschrijving ter aanduiding van de user story. Het is niet de bedoeling om volledige functionaliteit al tot in detail te beschrijven. Hiervoor is een ander onderdeel de user stories bedoeld: mondelinge communicatie. 'Mondeling' omdat het veel effectiever is om detailinformatie mondeling over te dragen.

Zodra de ontwikkelaar een user story gaat implementeren is detailinformatie nodig over de gewenste werking van de user stories. De korte omschrijving is té globaal, zodat het ontwikkelteam de gebruiker (product owner) vragen moet gaan stellen. De antwoorden op de vragen worden - voor zover nodig voor de correcte werking van de te realiseren software - vastgelegd als acceptatiecriteria. Door de samenwerking tussen het ontwikkelteam en de product owner is dus ook geen analist nodig als brugfunctie tussen business en ICT.

Deze acceptatiecriteria vormen het derde onderdeel van user stories. De acceptatiecriteria hoeven - omdat er intensief wordt samengewerkt bij het implementeren van de user stories - niet volledig te zijn. De kracht van het werken met user stories is volgens De Swart dan ook dat het detailleren van requirements, het ontwikkelen van de software en het testen ervan hand in hand gaan: "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."

Onderdelen user story

1. Korte beschrijving als aanduiding van de requirement (ivm planning)

2. Mondelinge communicatie om de details te achterhalen (tijdens de realisatie)

3. Acceptatiecriteria om juiste werking vast te stellen

De kracht van user stories zit in het feit dat door de intensieve samenwerking tussen het ontwikkelteam en de product owner en de nadruk op mondelinge communicatie drie voordelen optreden:

1. Eenvoud:"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".

2. Flexibiliteit: user stories kunnen beter omgaan met 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".

3. Snelheid: een user story moet in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, moeten worden opgesplitst. Kom daar maar eens om, bij een volledige use case. Het is niet langer een analist gedetailleerd requirements te laten specificeren. Verder gaat ook geen tijd verloren aan het lezen en begrijpen van gedetailleerde requirements door de ontwikkelaars en testers en is het - omdat detaillering van requirements later en mondeling plaatsvindt - niet nodig om wijzigingen door te voeren in de specificaties.

Bron: Nicole de Swart op http://www.reaco.nl/kenniscentrum/userStories.asp