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

Zestien voorbeelden van gebruikersverhalen met toelichting op het gebied van authenticatie, e-commerce, mobiele toepassingen, API’s en bugs, waarbij de onjuiste versies naast de herziene versies worden weergegeven, zodat het verschil duidelijk zichtbaar is.

Zestien voorbeelden van user stories, afkomstig uit 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 voorbeelden zijn opzettelijk slecht opgesteld en worden naast hun herziene versies getoond, omdat u de opmaak het snelst leert door te zien hoe deze mislukt.

Als het formaat zelf nieuw voor u is, begin dan met Wat is een user story?. Kort gezegd volgt elk verhaal hier de structuur “Als [rol], wil ik [doel], zodat [voordeel]”, en elk goed verhaal 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 aanmeldscherm 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 zin wordt een concrete kostenpost genoemd. Elke reset die via de ondersteuning verloopt, vertegenwoordigt meetbare kosten; daarom kan aan dit verhaal op basis van feiten – en niet op basis van gevoel – voorrang worden gegeven boven andere zaken. Let op wat de zin niet bevat: het verlopen van tokens, tarieflimieten en het e-mailsjabloon. Die details horen thuis in de acceptatiecriteria, die worden opgesteld wanneer het team deze verder uitwerkt:

  • Binnen twee minuten na het verzoek ontvangt u een e-mail om uw wachtwoord opnieuw in te stellen.
  • 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, zodat de ‘zodat’-zin zou 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 beoogt af te dwingen.

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 laat zien dat de relevante tijdsperiode voor het behoud van klanten in dit geval 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 uiteengezet: aarzeling staat de eerste aankoop in de weg. Dergelijke heldere uiteenzettingen brengen meningsverschillen ook al in een vroeg stadium aan het licht: als het bedrijf wil dat elke koper een account heeft, dan wordt die discussie gevoerd tijdens de verdere uitwerking, en niet in de pull-request.

6. De metrische figuur in een kostuum uit een verhaal

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 ik via mijn telefoon iets koop, 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 toetsbaar en klein genoeg zijn om te overzien.

Mobiel

7. Offline-modus

Als buitendienstmedewerker wil ik dat de werkbon van vandaag 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 nooit op; buitendiensttechnici leven ermee. 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 melding wil ontvangen, 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. Paginering

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

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

10. Rate limiting

Als API-gebruiker wil ik een 429-antwoord met een Retry-After-header ontvangen wanneer ik de verwerkingslimiet bereik, zodat mijn client het verzoek kan uitstellen in plaats van de gehele taak te laten mislukken.

Waarom dit werkt: het doel is nauwkeurig genoeg om op zichzelf al het eerste acceptatiecriterium te vormen, 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-aanpak die wordt toegepast op werkzaamheden waarvoor deze niet is bedoeld; 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 specifieke aanbieders, zodat een nieuwe betalingsaanbieder kan worden toegevoegd zonder ingrepen in de kern van het afrekenproces. Dit is voltooid wanneer: de aanbiedersinterface is gescheiden, de twee bestaande aanbieders daarachter draaien en de reeks integratietests ongewijzigd slaagt.

Een eenvoudig technisch onderwerp met een duidelijk omschreven resultaat is altijd beter dan een verhaal vol fantasie.

Een fout of een verhaal?

12. De bug die 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 controleren 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 aan vastgesteld, de omvang wordt bepaald en het krijgt een plaats in de sprint. Het toekennen van punten aan bugoplossingen zorgt ervoor dat de velocity een getrouw beeld geeft 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 gereproduceerd.

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 dubbel in rekening wordt gebracht…“) zou weliswaar waar zijn, maar nutteloos, en elke schatting zou slechts een uitdrukking van hoop zijn. De juiste aanpak is een spike: onderzoek gedurende twee dagen, rapporteer de verkregen inzichten en schrijf vervolgens het daadwerkelijke verhaal voor de oplossing.

Interne hulpmiddelen en rapportage

14. Ondersteunende hulpmiddelen

Als medewerker van de livechat-klantenservice 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“-clausule bakent de opdracht stilletjes af. Het delen buiten de tool is de opdracht, wat oplossingen zoals in-app-dashboards en regels in saai, overdraagbaar CSV-formaat uitsluit. Een goede voordeelclausule verricht gratis ontwerpwerk.

16. Het verhaal van de zichtbaarheid

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

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

De herziene versie:

Als leveringsmanager die de statusvergadering 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

Kijkt u nog eens terug naar de twaalf die werken. Elk criterium 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 oprechte „waarom?”-vraag kan doorstaan. Geen enkel criterium bevat een implementatie, en geen enkel criterium probeert volledig te zijn. Daar zijn acceptatiecriteria en het verfijningsgesprek voor bedoeld.

De vier slechte verhalen mislukken op precies twee manieren, 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 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 vanuit het perspectief van die persoon, en de reden waarom het de moeite waard is om deze taak in te plannen. Deze driedelige opbouw (rol, doel, voordeel) vormt 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 zin van het verhaal 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 worden meegenomen, 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 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 dient een user story te zijn?

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

Aanbevolen lectuur