Definitie: Een user story is een korte beschrijving van een functie vanuit het perspectief van de gebruiker: wie het is, wat die wil kunnen en waarom. De standaardvorm is “Als (rol) wil ik (iets kunnen), zodat (doel)”, aangevuld met acceptatiecriteria die bepalen wanneer de story af is.
In het kort
- User stories komen uit Extreme Programming; Kent Beck introduceerde ze in 1997 bij het Chrysler C3-project.
- Het bekendste sjabloon, “Als … wil ik … zodat …”, werd volgens Wikipedia in 2001 bedacht door het team van Connextra in Londen.
- Een user story is vooral een aanleiding voor een gesprek, niet een volledige specificatie. Ron Jeffries vatte dat samen in drie C’s: Card, Conversation en Confirmation.
- Grote stories heten epics en worden opgesplitst tot ze binnen één sprint af te ronden zijn.
Wat is een user story?
Een user story beschrijft een stukje software in de taal van de gebruiker. Niet “voeg een tabel met kolommen toe”, maar wat iemand ermee wil bereiken. Daardoor blijft het gesprek gaan over het probleem dat je oplost, en niet alleen over de techniek.
Een user story is bewust kort. TechTarget beschrijft het als iets wat op een sticky note past. De details komen in het gesprek tussen opdrachtgever, gebruikers en ontwikkelaars, en worden vastgelegd in acceptatiecriteria. Mountain Goat Software, het bedrijf van Mike Cohn, benadrukt dat het belangrijkste doel van een user story is om dat gesprek op gang te brengen.
Waar komen user stories vandaan?
Volgens Wikipedia gebruikte Kent Beck user stories voor het eerst in 1997, bij het C3-project van Chrysler in Detroit. In 1999 beschreef hij ze in zijn boek over Extreme Programming. Ron Jeffries voegde in 2001 het model van de drie C’s toe, en in hetzelfde jaar ontstond bij Connextra het bekende sjabloon. Mike Cohn maakte user stories in 2004 breed bekend met zijn boek User Stories Applied. Inmiddels worden ze gebruikt in Scrum, Kanban en vrijwel elke agile werkwijze.
Hoe schrijf je een user story? (template)
Het sjabloon:
Als (rol of type gebruiker) wil ik (iets kunnen doen) zodat (het doel of voordeel).
Drie onderdelen, drie vragen:
- Wie? Een echte gebruiker, zoals een klant, planner of beheerder. Agile Academy wijst erop dat de gebruiker geen database, server of ontwikkelaar moet zijn.
- Wat? De handeling of mogelijkheid, zonder al de technische oplossing te kiezen.
- Waarom? Het doel. Volgens Wikipedia ziet Cohn het zodat-deel als optioneel, maar het helpt vaak om de juiste oplossing te kiezen.
Voorbeelden van user stories
| Rol | Wil ik | Zodat |
|---|---|---|
| Klant | mijn openstaande facturen in het portaal zien | ik niet hoef te mailen om een overzicht te vragen |
| Planner | opdrachten slepen naar een monteur in de weekplanning | ik snel kan schuiven als iemand ziek is |
| Monteur | op mijn telefoon zien welke opdrachten ik vandaag heb | ik weet waar ik heen moet zonder te bellen |
| Verkoper | een herinnering krijgen voor offertes zonder reactie | geen aanvraag blijft liggen |
| Beheerder | gebruikers een rol geven | iedereen alleen ziet wat bij zijn werk hoort |
Wat zijn acceptatiecriteria?
Acceptatiecriteria beschrijven wanneer een user story af is. Ze zijn de Confirmation uit de drie C’s. Volgens Mike Cohn moeten alle criteria gehaald zijn voordat de product owner een story accepteert.
Voorbeeld bij “Als klant wil ik mijn openstaande facturen in het portaal zien”:
- De klant ziet alleen facturen van zijn eigen organisatie.
- Per factuur staan nummer, datum, bedrag en vervaldatum.
- Vervallen facturen zijn duidelijk gemarkeerd.
- De klant kan elke factuur als PDF downloaden.
- Zijn er geen openstaande facturen, dan staat er een duidelijke melding.
Sommige teams schrijven criteria in de vorm “Gegeven … wanneer … dan …”, zodat ze direct als test bruikbaar zijn.
Wat maakt een user story goed?
Een veelgebruikte toets is INVEST:
| Letter | Betekenis |
|---|---|
| I, Independent | Zo veel mogelijk los van andere stories te bouwen |
| N, Negotiable | Ruimte voor gesprek over de uitwerking |
| V, Valuable | Levert waarde op voor de gebruiker |
| E, Estimable | Het team kan inschatten hoeveel werk het is |
| S, Small | Past binnen één sprint |
| T, Testable | Er is duidelijk wanneer het werkt |
ProductPlan noemt een sprint van meestal twee weken; past een story daar niet in, dan splits je hem op.
User story, epic en use case: wat is het verschil?
| Begrip | Omvang | Doel |
|---|---|---|
| User story | Klein, binnen één sprint | Eén wens van een gebruiker beschrijven |
| Epic | Groot, meerdere sprints | Een verzameling samenhangende stories, zoals “facturen in het portaal” |
| Use case | Gedetailleerd | Volgens ProductPlan de voorwaarden, hoofdstroom en alternatieve stromen vastleggen |
Hoe splits je een grote user story?
Een story die niet in één sprint past, splits je op. Mountain Goat Software raadt aan om niet alleen op technische lagen te splitsen, zoals eerst de database en later het scherm, omdat elk deel dan los geen waarde heeft. Beter is splitsen op wat de gebruiker kan doen. Een paar manieren:
- Op stap in het proces. “Factuur bekijken” en “factuur downloaden” als aparte stories.
- Op variant. Eerst betalen met iDEAL, later met creditcard.
- Op regel of uitzondering. Eerst de standaardsituatie, daarna afwijkende gevallen zoals creditnota’s.
- Op gegevens. Eerst de facturen van het lopende jaar, daarna het archief.
- Op eenvoud. Eerst een eenvoudige versie die werkt, daarna de verfijning.
Elk deel moet op zichzelf iets opleveren dat een gebruiker kan testen. Zo kan het team na elke sprint laten zien wat er werkt, en kan de opdrachtgever bijsturen voordat alle onderdelen klaar zijn. Dat voorkomt dat een fout pas aan het eind zichtbaar wordt.
Van user stories naar een eerste versie
User stories zijn handig om een eerste versie af te bakenen. Zet alle stories op een rij en bepaal per story of hij nodig is om de belangrijkste taak van de gebruiker mogelijk te maken. Wat niet nodig is, schuift door naar een volgende versie. Zo ontstaat een overzichtelijke lijst die de basis vormt voor de planning en het gesprek over prioriteiten. Een product backlog is in feite die geordende lijst van stories.
Veelgemaakte fouten
- Technische taken als story. “Als ontwikkelaar wil ik een database” beschrijft geen waarde voor een gebruiker.
- Te groot. Een story die weken kost, is een epic.
- Geen acceptatiecriteria. Dan is niet duidelijk wanneer iets af is.
- Het waarom weglaten. Zonder doel kies je makkelijk de verkeerde oplossing.
- Alles vooraf uitschrijven. De kracht zit in het gesprek tijdens het bouwen.
Wat betekent dit voor jouw project?
Bij een nieuw idee stel ik altijd de vraag: wie gaat het gebruiken en welke taak moet die persoon als eerste kunnen afronden? Dat is in feite de eerste user story. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen, en een handvol goede stories met acceptatiecriteria maakt dat concreet.
Bij Webinooo, mijn eigen webinarproject, is de registratie gebouwd en getest. De les daaruit: ontwerp vanuit het moment van de gebruiker. Wat verwacht iemand na inschrijving, hoe weet hij wat er gaat gebeuren en waar gaat hij verder? Dat zijn precies de vragen die een user story beantwoordt.
Vraag? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe ik een webapplicatie ontwikkel.
Veelgestelde vragen over user stories
Wat is een user story?
Een user story is een korte beschrijving van een functie vanuit het perspectief van de gebruiker, in de vorm “Als (rol) wil ik (iets kunnen), zodat (doel)”. Acceptatiecriteria bepalen wanneer de story af is.
Hoe ziet een user story voorbeeld eruit?
Een voorbeeld is: “Als klant wil ik mijn openstaande facturen in het portaal zien, zodat ik niet hoef te mailen om een overzicht te vragen.” Acceptatiecriteria leggen vast welke gegevens zichtbaar zijn en wat er gebeurt als er geen facturen zijn.
Wie schrijft de user stories?
Vaak schrijft de product owner de user stories, maar volgens ProductPlan is het een gedeelde verantwoordelijkheid van het team. Gebruikers en opdrachtgevers leveren de input, ontwikkelaars helpen ze scherp en klein genoeg te maken.
Verwante termen
Product backlog · Scrum · Sprint · Functionele eisen · Programma van eisen · Agile
← Terug naar de kennisbank