Sjabloon voor gebruikersverhalen en acceptatiecriteria

Het sjabloon voor een user story bestaat uit één zin met drie lege plekken:

Als [rol] wil ik [doel], zodat [voordeel].

Kopieer het, gebruik het, maar weet waarvoor het dient: het sjabloon is een aanleiding voor een gesprek, geen formulier dat u moet invullen. Een ingevulde zin is waar de verfijning begint. Wat het verhaal werkbaar maakt, is wat er vervolgens aan wordt toegevoegd — de acceptatiecriteria die een overeengekomen intentie omzetten in een goed/fout-test, en de schatting die er planbaar werk van maakt. Dit hoofdstuk behandelt één verhaal aan de hand van alle drie deze stappen.

De lege plekken invullen zonder ze te verzinnen

Elke sleuf kent een veelvoorkomende storing, en elke storing kan worden gecontroleerd:

• [rol] — een specifieke persoon, nooit „een gebruiker”. Als u deze persoon niet zou kunnen herkennen in uw analysegegevens of uw supportwachtrij, dan is de rol louter decoratie. Test: zou een ontwerper op basis van de door u gekozen rol een andere beslissing kunnen nemen?
• [doel] — wat de persoon doet, in zijn of haar eigen woorden. „Ik wil mijn wachtwoord opnieuw instellen” hoort thuis bij de gebruiker; „Ik wil een microservice voor het opnieuw instellen van wachtwoorden” hoort thuis in het architectuurdiagram. Test: zou de persoon deze zin daadwerkelijk uitspreken?
• [voordeel] — het argument om het werk in te plannen. Test: verwijder de zin. Als er niets verloren gaat, is het voordeel nog niet vastgesteld.

De volledige onderbouwing van dit formaat — inclusief de drie C’s en de INVEST-checklist waaraan een voltooid verhaal moet voldoen — vindt u in Wat is een user story?. Zestien praktijkvoorbeelden, zowel goede als slechte, vindt u in Voorbeelden van user stories.

Een kopieer-en-plak-verhaalkaart

Deze zin alleen is niet voldoende om ermee aan de slag te gaan bij een sprint. Hier volgt het volledige kaartformaat dat als standaard zou moeten worden gehanteerd — verhaal, criteria, grenzen en als laatste de omvang:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Er zijn twee bewuste keuzes gemaakt in die kaart. “Buiten het bereik” is doorslaggevend: bij de meeste discussies over schattingen gaan twee personen uit van verschillende reikwijdtes, en één regel hier voorkomt dat. De omvang komt pas op de laatste plaats: een getal dat op de kaart wordt geschreven voordat het team erover heeft gediscussieerd, wordt een ankerpunt, wat de eerste van de klassieke fouten bij planning poker is.

Sjabloonvarianten

Het klassieke sjabloon is de juiste standaardinstelling, maar het is niet de enige vorm die geschikt is.

Variant	Vorm	Pak het aan wanneer
Classic (Connextra)	Als [functie] wil ik [doel], zodat [voordeel]	De standaardaanpak voor werkzaamheden die rechtstreeks met de gebruiker te maken hebben
Functieomschrijving	Wanneer [situatie], wil ik [motivatie], zodat ik [resultaat] kan bereiken	Het moment waarop iets in gang wordt gezet, zegt meer dan het imago alleen — dezelfde persoon wil in de trein andere dingen dan achter een bureau
Voordelen voorop	Om [voordeel] te behalen, wil ik als [functie] [doel] bereiken	Het team blijft cirkelredeneringen opstellen; door de clausule als eerste te vermelden, wordt het onmogelijk om deze over te slaan
Eenvoudige probleemstelling	Eén zin over het probleem, één over het resultaat, plus criteria voor „wanneer het af is“	Platform- en technische werkzaamheden waarbij het team zelf de enige betrouwbare partij zou zijn

De laatste regel is belangrijker dan op het eerste gezicht lijkt. Bij sommige backlog-items ontbreekt de gebruiker in de zin, en als men doet alsof dat wel het geval is, leidt dat tot opvultekst zoals „als ontwikkelaar wil ik dat het framework wordt geüpgraded”. De structuur van het sjabloon — een duidelijk omschreven reden plus toetsbare criteria — wordt in dat werk overgenomen; de vorm van de zin hoeft dat niet te zijn.

Acceptatiecriteria: de bevestiging op de kaart

Acceptatiecriteria zijn de voorwaarden waarop een story wordt goedgekeurd of afgekeurd, en worden vastgelegd voordat met de werkzaamheden wordt begonnen. Op de kaart vervullen zij twee functies: zij geven weer wat er daadwerkelijk tijdens het verfijningsgesprek is overeengekomen, en zij bepalen de einddoelstelling waarop de schatting is afgestemd. Er zijn twee formaten die voor vrijwel elke story geschikt zijn:

Een eenvoudige checklist, voor onafhankelijke omstandigheden:

• De inhoud van het winkelmandje blijft gedurende 30 dagen bewaard, ook als u de sessie afsluit.
• Een terugkerende klant kan het winkelmandje vanaf elk apparaat waarop hij of zij is ingelogd bekijken.
• Een leeggemaakt winkelwagentje blijft leeg (verwijderde artikelen worden niet hersteld).

Gegeven/Wanneer/Dan, voor gedrag dat afhankelijk is van de toestand:

• Als een klant een opgeslagen winkelmandje heeft, wanneer een artikel niet meer op voorraad is, dan wordt het artikel in het winkelmandje grijs weergegeven met het label „niet op voorraad”, in plaats van dat het stilletjes wordt verwijderd.

Gebruik standaard de checklist; pas de Given/When/Then-methode toe wanneer de voorwaarde daadwerkelijk werk verricht. Beperk de lijst tot drie tot vijf punten — een langere lijst betekent meestal dat het verhaal moet worden opgesplitst, en de criteria geven u de scheidingslijnen aan. Voor een uitgebreide behandeling (criteria versus vereisten, criteria versus definitie van ‘klaar’, wie ze opstelt), zie het hoofdstuk over acceptatiecriteria.

Praktijkvoorbeeld: één verdieping, sjabloon voor een schatting

Hier ziet u het verloop van een echt verhaal, aan de hand van de bovenstaande kaart.

Stap 1 — het verhaal. De producteigenaar schrijft:

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

Stap 2 — het gesprek, vastgelegd als criteria. Bij backlogverfijning brengt het team de nuances naar voren die in de zin niet tot uiting komen, en noteert deze:

• Een koper kan de bestelling afronden met alleen zijn e-mailadres en verzendgegevens, zonder wachtwoord.
• In de e-mail met de orderbevestiging wordt de mogelijkheid geboden om met één klik een account aan te maken (de bestelling is al gekoppeld).
• Een bestelling van een gast kan door de klantenservice worden teruggevonden aan de hand van het bestelnummer en het e-mailadres.
• Bij het afrekenen als gast worden dezelfde fraudecontroles uitgevoerd als bij het afrekenen via een account.

Valt buiten het toepassingsgebied: het omzetten van eerdere bestellingen van gasten wanneer er later een account wordt aangemaakt.

Stap 3 — de gereedheidscontrole. Vier criteria, één benoemde uitsluiting, geen onbevestigde afhankelijkheden: het verhaal voldoet aan de definitie van ‘gereed’ en wordt doorgestuurd naar het team voor het bepalen van de omvang.

Stap 4 — de schatting. Het team stemt in een ronde planning poker. Er worden kaarten getrokken met de waarden 3, 5, 5 en 8. De 8 wordt toegelicht: het criterium voor fraudecontrole houdt in dat er aan de integratie met de betalingsprovider moet worden gewerkt, iets waar niemand anders rekening mee had gehouden bij het maken van de schatting. Dat is hoe de criteria hun werkelijke functie vervullen — de discussie gaat over de omvang van de opdracht, niet over wiens schatting juist is. Het team stemt opnieuw en komt uit op 5.

Let op de volgorde: eerst de criteria, daarna de punten. Een story waarvan de omvang wordt geschat voordat de criteria vaststaan, leidt tot brede, onoplosbare spreidingen die de sizing-sessies vertragen — het team stemt dan namelijk over verschillende stories die toevallig dezelfde titel hebben.

Veelgestelde vragen

Wat is het sjabloon voor een user story?

“Als [rol] wil ik [doel], zodat [voordeel].” De rol geeft aan wie de waarde ontvangt, het doel benoemt de capaciteit in de termen van die persoon, en het voordeel is de reden waarom het werk een plaats in de backlog verdient. Het sjabloon is een aanleiding voor een gesprek, geen formulier dat moet worden ingevuld — het invullen van de lege velden is waar de verfijning begint.

Hoe stelt u acceptatiecriteria op voor een user story?

Stel drie tot vijf toetsbare voorwaarden op die aangeven – geslaagd of niet geslaagd – of het verhaal voldoet aan wat was afgesproken. Gebruik een eenvoudige checklist wanneer de voorwaarden onafhankelijk van elkaar zijn, en de Given/When/Then-structuur wanneer het gedrag afhankelijk is van de toestand. Elk criterium moet kunnen worden gecontroleerd door een tester die niet aanwezig was bij het verfijningsgesprek.

Moeten acceptatiecriteria worden opgesteld volgens het „Given/When/Then“-model of aan de hand van een checklist?

Stem de opzet af op het gedrag. Given/When/Then bewijst zijn nut wanneer de uitkomst afhankelijk is van een begintoestand, omdat het u dwingt om de voorwaarde, de aanleiding en het resultaat te benoemen. Een checklist is sneller te lezen en moeilijker op te smukken wanneer het verhaal simpelweg luidt: „deze vier dingen moeten waar zijn.” Voor de meeste verhalen volstaat de checklist.

Wat is een ‘job story’?

Een variant waarbij de persona wordt vervangen door een situatie: „Wanneer [situatie], wil ik [motivatie], zodat ik [resultaat] kan bereiken.” Jobverhalen zijn afkomstig uit de ‘jobs-to-be-done’-school en werken goed wanneer het uitlokkende moment de behoefte beter verklaart dan een persona dat doet — dezelfde persoon wil namelijk verschillende dingen achter zijn bureau en in de trein.

Moet voor elk backlog-item het sjabloon voor de user story worden gebruikt?

Nee. Het sjabloon beschrijft de waarde voor de gebruiker, en wanneer u dit opdringt aan platformwerk, bekende bugs of onderzoekspieken, leidt dit tot zinnen die alleen maar omhaal van woorden opleveren zonder daadwerkelijke informatie. Houd vast aan de twee elementen die altijd van toepassing zijn — een duidelijk omschreven reden en toetsbare acceptatiecriteria — en laat de vorm van de zin zich aanpassen aan het werk.

Aanbevolen lectuur

• Agile-inschatting: de complete gids — hier vindt u alle informatie hierover.
• Wat is een user story? — de reden achter het sjabloon: de drie C’s en INVEST.
• Voorbeelden van user stories — zestien user stories met toelichting, die als referentiepunt kunnen dienen.
• Acceptatiecriteria: hoe schrijft u ze? — het volledige hoofdstuk over de bevestigingsfase.
• Definitie van ‘ready’ — de poort die een op een sjabloon gebaseerd verhaal moet passeren om in de sprint te worden opgenomen.
• Wat zijn story points? — de eenheid waarin de omvang van de voltooide kaart wordt uitgedrukt.