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 steekplaats kent een veelvoorkomende storing, en elke storing kan worden gecontroleerd:

• [rol]: een specifieke persoon, nooit „een gebruiker”. Als u deze persoon niet uit uw analysegegevens of uw supportwachtrij zou kunnen herkennen, is de rol louter decoratief. 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 het artikel „Wat is een user story?“. Zestien praktijkvoorbeelden, zowel goede als slechte, zijn te vinden in „Voorbeelden van user stories“.

Een kopieer-en-plak-verhaalkaart

Deze zin alleen is niet voldoende om ermee aan de slag te gaan tijdens een sprint. Hier volgt het volledige kaartformaat dat als standaard kan dienen, met het verhaal, de criteria, de grenzen en ten slotte 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 op die kaart. “Buiten het bereik” is doorslaggevend: bij de meeste discussies over schattingen hebben twee personen het over verschillende reikwijdtes, en één regel hier voorkomt dat. De omvang komt pas op het laatst: een getal dat op de kaart wordt geschreven voordat het team erover heeft gesproken, wordt een ankerpunt, wat de eerste van de klassieke fouten bij planning poker is.

Sjabloonvarianten

Het klassieke sjabloon is de juiste standaardinstelling, en 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 in contact staan met de gebruiker
Functieomschrijving	Wanneer [situatie], wil ik [motivatie], zodat ik [resultaat] kan bereiken	Het uitlokkende moment zegt meer dan het imago (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 niet zo 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 ziet het winkelmandje vanaf elk apparaat waarop hij of zij is ingelogd.
• 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 de checklist als uitgangspunt; 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 doorgaans dat het verhaal moet worden opgesplitst, en de criteria geven u aan waar de scheidslijnen liggen. Voor een uitgebreide behandeling (criteria versus vereisten, criteria versus definitie van ‘klaar’, wie ze opstelt), raadpleegt u het hoofdstuk over acceptatiecriteria.

Praktijkvoorbeeld: één verdieping, sjabloon voor het maken van een schatting

Hier volgt 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 het verfijnen van de backlog brengt het team de nuances naar voren die de zin niet weergeeft, en schrijft deze op:

• 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 muisklik een account aan te maken (de bestelling is al bijgevoegd).
• 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 de prijsbepaling. 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 schatting wordt gemaakt voordat de criteria vaststaan, leidt tot brede, onoplosbare spreidingen die de sizing-sessies vertragen. Het team stemt uiteindelijk 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 mislukt – of het verhaal heeft opgeleverd wat was afgesproken. Gebruik een eenvoudige checklist wanneer de voorwaarden onafhankelijk van elkaar zijn, en ‘Given/When/Then’ 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 trigger 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 van toepassing 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.” Job stories 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 aan zijn bureau andere dingen dan 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 men 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 aansluiten bij het werk.

Aanbevolen lectuur

• Agile-inschatting: de complete gids: hier vindt u alle informatie.
• Wat is een user story?: de redenen achter het sjabloon, de drie C’s en INVEST.
• Voorbeelden van gebruikersverhalen: zestien verhalen met toelichting om uw eigen verhalen aan af te stemmen.
• Acceptatiecriteria: hoe u deze opstelt: het volledige hoofdstuk over de bevestigingsfase.
• Definitie van ‘gereed’: de poort die een op een sjabloon gebaseerd verhaal passeert op weg naar de sprint.
• Wat zijn story points?: de eenheid waarin de omvang van de voltooide kaart wordt uitgedrukt.