Voorbeelden van user stories: 16 verhalen met toelichting, zowel goede als slechte

Zestien voorbeelden van user stories, ontleend aan de domeinen waarin teams daadwerkelijk werkzaam zijn: authenticatie, e-commerce, mobiele toepassingen, API’s, bugs en interne tools. Elk voorbeeld is voorzien van toelichting — niet alleen wat de story precies inhoudt, maar ook waarom de rol- en voordeelclausules hun nut bewijzen. Vier daarvan zijn opzettelijk slecht opgesteld en worden naast hun herschreven versies getoond, omdat de snelste manier om het formaat onder de knie te krijgen, is door te zien hoe het misgaat.

Als het format zelf nieuw voor u is, begin dan met Wat is een user story? — kort gezegd volgt elk verhaal hier de indeling “Als [rol], wil ik [doel], zodat [voordeel]”, en elke goede user story kan direct worden gebruikt voor verfijning en een ronde planning poker.

Authenticatie en accounts

1. Inloggen

Als terugkerende klant wil ik inloggen met mijn e-mailadres en wachtwoord, zodat ik mijn bestelgeschiedenis kan bekijken.

Waarom dit werkt: de rol is specifiek. „Terugkerende klant” geeft aan dat deze persoon een account heeft, eerder een bestelling heeft geplaatst en een reden heeft om terug te komen — drie feiten waar een ontwerper en een tester gebruik van kunnen maken. „Als gebruiker” zou geen van deze feiten hebben weergegeven.

2. Wachtwoord opnieuw instellen

Als gebruiker die geen toegang meer heeft tot zijn account, wil ik mijn wachtwoord vanaf het inlogscherm opnieuw instellen, zodat ik weer toegang tot mijn account kan krijgen zonder contact op te nemen met de helpdesk.

Waarom dit werkt: in de voorwaardelijke clausule wordt een concrete kostenpost genoemd. Elke reset die via de helpdesk verloopt, vertegenwoordigt meetbare kosten; daarom kan dit probleem op basis van feiten – en niet op basis van gevoel – voorrang krijgen boven andere problemen. Let op wat de zin niet vermeldt: het verlopen van tokens, tarieflimieten en het e-mailsjabloon. Die details horen thuis in de acceptatiecriteria, die worden opgesteld wanneer het team het probleem verder uitwerkt:

• Binnen twee minuten na het verzoek ontvangt u een e-mail met een resetlink.
• De resetlink verloopt na één uur en kan één keer worden gebruikt.
• Het formulier geeft hetzelfde antwoord, ongeacht of het e-mailadres bestaat of niet (er vindt geen account-enumeratie plaats).

3. Het cirkelvormige verhaal

Als gebruiker wil ik inloggen, zodat ik toegang krijg tot de app.

Waarom dit niet voldoet: alle velden zijn ingevuld, maar er wordt niets gezegd. De rol is ‘niemand in het bijzonder’ en in het voordeel wordt het doel herhaald; de ‘zodat’-zin zou dus kunnen worden geschrapt zonder dat er informatie verloren gaat. Een verhaal als dit doorstaat de formaatcontrole, maar gaat voorbij aan alle denkwerk dat het formaat juist juist zou moeten afdwingen.

De herziene versie:

Als projectlid dat halverwege een sprint terugkeert, wil ik na het inloggen direct op het bord terechtkomen dat ik het laatst heb bekeken, zodat ik daar niet elke ochtend opnieuw naartoe hoef te navigeren.

Nu is er een persoon, een moment en een voordeel dat iemand zou kunnen afwegen tegen ander werk.

E-commerce

4. Persistentie van het winkelmandje

Als klant die tijdens mijn lunchpauze wat rondkijkt, wil ik dat de artikelen in mijn winkelmandje bewaard blijven tot ik vanavond terugkom, zodat ik niet alles opnieuw hoef te zoeken.

Waarom dit werkt: de rol bevat een scenario. „Rondkijken tijdens mijn lunchpauze” verklaart waarom winkelwagentjes halverwege het aankoopproces worden achtergelaten, wat het team duidelijk maakt dat de relevante tijdsperiode hier uren is, en geen seconden. Een goed gekozen rol verwerkt de context in één enkele zin.

5. Afrekenen als gast

Als nieuwe klant wil ik afrekenen zonder een account aan te maken, zodat ik mijn aankoop kan afronden voordat ik van gedachten verander.

Waarom dit werkt: er wordt een productpositie ingenomen (accounts zijn optioneel) en het daadwerkelijke voordeel wordt duidelijk aangegeven — aarzeling staat de eerste aankoop in de weg. Dergelijke heldere verhalen brengen meningsverschillen ook al in een vroeg stadium aan het licht: als het bedrijf wil dat elke koper een account heeft, wordt die discussie gevoerd tijdens de verdere uitwerking, niet in de pull-request.

6. De metrische figuur in een verhaalpak

Als klant wil ik een sneller en overzichtelijker afrekenproces, zodat de conversie toeneemt.

Waarom dit niet werkt: om twee redenen. “Sneller, schoner” is geen eigenschap die iemand kan ontwikkelen of testen, en “de conversie verbetert” is het voordeel voor het bedrijf, niet voor de klant — geen enkele klant wil conversie. Dit is een kwartaal aan werk samengevat in één zin, waardoor het een episch verhaal is, geen verhaal.

De herschreven versie (een fragment daaruit):

Als koper die via mijn telefoon winkelt, wil ik dat mijn verzendadres automatisch wordt ingevuld op basis van mijn postcode, zodat ik het afrekenen met één hand kan afronden.

Het epische project bestaat uit een reeks van dit soort onderdelen, die stuk voor stuk testbaar en klein genoeg zijn om te kunnen worden afgehandeld.

Mobiel

7. Offline-modus

Als buitendienstmedewerker wil ik dat de werkbon van vandaag ook zonder internetverbinding wordt geladen, zodat ik in kelders en gebieden zonder bereik kan blijven werken.

Waarom dit werkt: de functie bepaalt de vereiste. Kantoormedewerkers merken offline ondersteuning niet eens op; buitendienstmedewerkers zijn er volledig mee vertrouwd. Wanneer iemand tijdens de verfijning vraagt: „Hoe offline is offline?”, heeft de functie het antwoord al gegeven: overal waar de klus hen naartoe brengt.

8. Voorkeuren voor meldingen

Als abonnee die drie pushmeldingen per dag ontvangt, wil ik zelf kunnen kiezen voor welke soorten meldingen ik een notificatie ontvang, zodat ik niet langer de hele app op stil hoef te zetten.

Waarom dit werkt: het voordeel benoemt de foutmodus die het verhaal voorkomt. Gebruikers klagen niet over het aantal meldingen; zij zetten de app op stil en haken stilletjes af. Een verhaal dat het stille gedrag benoemt waartegen het zich verzet, is een verhaal waarover het team oprecht van gedachten kan wisselen.

API’s en technische werkzaamheden

9. Paginanummering

Als integratieontwikkelaar wil ik gepagineerde reacties op het /events-eindpunt, zodat mijn nachtelijke synchronisatie bij grote accounts niet in een time-out terechtkomt.

Waarom dit werkt: dit is de legitieme technische gebruikersverhaal — de ontwikkelaar is een echte, externe gebruiker met eigen doelstellingen, en niet het team dat zichzelf in de zin opneemt. API-gebruikers, makers van plug-ins en operators die dienst hebben, voldoen allemaal aan deze eis.

10. Beperking van het aantal verzoeken

Als API-gebruiker wil ik een 429-antwoord met een Retry-After-header ontvangen wanneer ik de limiet bereik, zodat mijn client even kan wachten in plaats van de hele taak te laten mislukken.

Waarom dit werkt: het doel is zo nauwkeurig dat het op zichzelf al als eerste acceptatiecriterium kan dienen, en het blijft een wat, geen hoe — er wordt hier niets voorgeschreven over de manier waarop de begrenzer moet worden geïmplementeerd.

11. De verkapte refactor

Als ontwikkelaar wil ik de betalingsmodule herstructureren, zodat de code overzichtelijker wordt.

Waarom dit niet werkt: de rol is het team, het doel is een activiteit in plaats van een resultaat, en „schoner” is niet toetsbaar. Dit is de user story-methode die wordt toegepast op werk waarvoor deze niet is ontworpen — een geval dat wordt behandeld in wanneer user stories het verkeerde hulpmiddel zijn.

De herschreven versie (bewust geen user story):

Verminder de afhankelijkheid van de betalingsmodule ten opzichte van de betalingsprovider, zodat een nieuwe betalingsprovider kan worden toegevoegd zonder ingrepen in de kern van het afrekenproces. Dit is voltooid wanneer: de providerinterface is geëxtraheerd, de twee bestaande providers daarachter draaien en de reeks integratietests ongewijzigd slaagt.

Een eenvoudig technisch onderwerp met een duidelijk omschreven resultaat wint het altijd van een verhaal vol fantasie.

Is dit een fout of een verhaaltje?

12. Het insect dat een verhaal is

Als klant met een jaarabonnement wil ik dat op mijn factuur de korting wordt vermeld die mij is toegezegd, zodat de financiële afdeling de gegevens kan afstemmen zonder dat daarvoor een supportticket nodig is.

Waarom dit werkt: de oorzaak is bekend en de oplossing heeft een duidelijke reikwijdte, dus dit verloopt net als elk ander verhaal — er worden criteria vastgesteld, de omvang wordt bepaald en het krijgt een plek in de sprint. Door bugoplossingen specifiek aan te duiden, blijft de velocity een betrouwbare weergave van waar de capaciteit daadwerkelijk naartoe gaat; in het hoofdstuk over story points wordt dit argument uitgebreid toegelicht.

13. De bug die er niet is

Klanten melden af en toe dat er dubbel in rekening is gebracht. Dit kan niet op betrouwbare wijze worden nagebootst.

Waarom dit geen verhaal is: er is geen ruimte om iets te beloven. Een rol-doel-voordeel-zin („Als klant wil ik niet dat er twee keer kosten in rekening worden gebracht…“) zou weliswaar waar zijn, maar nutteloos, en elke schatting zou slechts een uitdrukking van hoop zijn. De juiste aanpak is een spike: twee dagen lang onderzoek doen, de verkregen inzichten presenteren en vervolgens het daadwerkelijke verhaal voor de oplossing opstellen.

Interne hulpmiddelen en rapportage

14. Ondersteunende hulpmiddelen

Als medewerker van de livechat-helpdesk wil ik de laatste vijf inlogpogingen van de klant kunnen zien, zodat ik in één oogopslag het verschil kan zien tussen een vergeten wachtwoord en een geblokkeerd account.

Waarom dit werkt: interne gebruikers zijn ook gebruikers. Het voordeel wordt gemeten in seconden per ticket, en dat is precies het soort concrete meerwaarde waardoor dit verhaal kan concurreren met klantgerichte werkzaamheden om een plek in de sprint, in plaats van automatisch te worden gepasseerd.

15. Uitvoer

Als teamleider wil ik het rapport over de sprint als CSV-bestand exporteren, zodat ik de resultaten kan delen met belanghebbenden die geen account hebben.

Waarom dit werkt: de „zodat“-zin bakent onopvallend het werk af. Het delen buiten de tool is de taak, wat oplossingen zoals in-app-dashboards en regels in saai, overdraagbaar CSV-formaat uitsluit. Een goede doelzin verricht gratis ontwerpwerk.

16. Het verhaal over zichtbaarheid

Als manager wil ik een overzicht van alles wat het team doet, zodat ik een goed beeld heb van de gang van zaken.

Waarom dit niet werkt: „alles“ is geen reikwijdte en „zichtbaarheid“ is geen resultaat — hier kan niets worden ontwikkeld, getest of in omvang worden vastgesteld. Achter een dergelijk verhaal schuilt een echte vraag die de manager nog niet is gesteld.

De herziene versie:

Als delivery manager die de statusbespreking van maandag voorbereidt, wil ik de sprintdoelstelling van elk team en de status (rood/oranje/groen) daarvan op één pagina hebben, zodat ik geblokkeerd werk kan markeren zonder elke teamleider apart te hoeven benaderen.

Dezelfde persoon, hetzelfde instinct, maar nu past het binnen een sprint en weet een tester wanneer het klaar is.

Wat de besten gemeen hebben

Kijk nog eens terug naar de twaalf die wel werken. Elk ervan noemt een persoon die specifiek genoeg is om een mening te hebben, vermeldt een doel dat die persoon zou herkennen, en biedt een voordeel dat een eerlijke „waarom?”-vraag kan doorstaan. Geen enkele bevat een implementatie, en geen enkele probeert volledig te zijn — daar zijn acceptatiecriteria en het verfijningsgesprek voor bedoeld.

De vier slechte verhalen schieten op precies twee manieren tekort, wat bemoedigend is: ofwel is het voordeel een cirkelredenering (niemand heeft nagegaan waarom), ofwel is de omvang een episch verhaal (niemand heeft nagegaan hoe groot). Beide tekortkomingen komen aan het licht op het moment dat uw team de story probeert in te schatten; daarom sporen sizing-sessies slechte stories sneller op dan welke schrijfrichtlijn dan ook — een grote spreiding in de stemmen is de foutmelding van deze methode. Schrijf uw volgende reeks verhalen aan de hand van het sjabloon, leg ze vervolgens met planning poker voor aan het team en kijk welke verhalen overeenstemming vinden.

Veelgestelde vragen

Wat is een voorbeeld van een user story?

“Als terugkerende klant wil ik inloggen met mijn e-mailadres en wachtwoord, zodat ik mijn bestelgeschiedenis kan bekijken.” Hierin wordt een specifieke persoon genoemd, een vaardigheid in de woorden van die persoon, en de reden waarom het de moeite waard is om deze taak in te plannen. Deze driedelige opbouw (rol, doel, voordeel) is de klassieke opzet van een user story.

Hoe schrijft u een goede user story?

Noem een specifieke rol in plaats van ‘een gebruiker’, formuleer het doel als iets wat de persoon doet in plaats van iets wat het systeem bevat, en sluit de ‘zodat’-zin af met een voordeel dat een oprechte ‘waarom?’-vraag zou doorstaan. Voeg vervolgens acceptatiecriteria toe, want de verhaalzin is een gespreksopener, niet de vereiste zelf.

Kan technisch werk als een user story worden opgesteld?

Soms. Als de „gebruiker” echt bestaat — een integratieontwikkelaar die uw API gebruikt, een operator die dienst heeft — werkt de opzet zoals beschreven. Als de enige relevante rol „het team” is, laat dan de schijn dan achterwege en schrijf een eenvoudig technisch item met een duidelijk omschreven resultaat en acceptatiecriteria. De werkwijze blijft hetzelfde; de zinsopbouw hoeft dat niet te zijn.

Moeten bugs als user stories worden opgesteld?

Een bug waarvan de oorzaak bekend is en waarvoor een duidelijke oplossing bestaat, kan wel als story worden opgenomen, en door deze aan te geven blijft de velocity realistisch. Een bug die niemand kan reproduceren, kan dat niet: er is geen ruimte om toezeggingen te doen, dus een story zou dan slechts een gok zijn met een clausule over de voordelen. Stel eerst een tijdslimiet vast voor het onderzoek en schrijf vervolgens de daadwerkelijke story op basis van de bevindingen.

Hoe gedetailleerd moet een user story zijn?

Eén zin die het verhaal weergeeft, gevolgd door drie tot vijf acceptatiecriteria. De zin vormt de aanleiding voor het gesprek; de criteria geven weer wat er tijdens dat gesprek is besloten. Als de lijst met criteria blijft groeien tot meer dan vijf, bestaat het verhaal in feite uit meerdere verhalen, en geven de criteria aan waar u het verhaal moet opsplitsen.

Aanbevolen lectuur

• Agile-inschatting: de complete gids — hier vindt u alle informatie hierover.
• Wat is een user story? — de opbouw, de drie C’s en de INVEST-checklist die aan elk van de bovenstaande voorbeelden ten grondslag liggen.
• Sjabloon voor gebruikersverhalen en acceptatiecriteria — een sjabloon die u kunt kopiëren en plakken, en een uitgewerkt voorbeeld tot en met de schatting.
• Het opsplitsen van user stories — wat te doen met de epics die in voorbeeld 6 en 16 verborgen zitten.
• Voorbeelden van agile schattingen — de bijbehorende serie: hoe het bepalen van de omvang van deze stories er in de praktijk in de vergaderruimte daadwerkelijk uitziet.