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 geslaagd/mislukt-test, en de schatting die het omzet in planbaar werk. Dit hoofdstuk behandelt één verhaal aan de hand van deze drie stappen.

De lege plekken invullen zonder ze te verzinnen

Elke slot vertoont 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 een beslissing anders nemen vanwege de rol die u hebt gekozen?
• [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 clausule. 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 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 in die kaart. “Buiten het bereik” is doorslaggevend: de meeste discussies over schattingen ontstaan doordat twee personen verschillende reikwijdtes beoordelen, 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 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 in contact staan met de gebruiker
Verhaal over een baan	Wanneer [situatie], wil ik [motivatie], zodat ik [resultaat] kan bereiken	Het uitlokkende moment zegt meer dan het imago (dezelfde persoon wil in de trein iets anders 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 waarin het probleem wordt beschreven, één waarin het resultaat wordt beschreven, plus criteria voor „voltooid wanneer“	Platform- en technische werkzaamheden waarbij het team zelf de enige betrouwbare speler 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 u 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 vormgeving 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 het werk 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 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 doorgaans 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 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 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 muisklik een account aan te maken (de bestelling is al toegevoegd).
• 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 story 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 die wordt ingeschat voordat de criteria daarvoor 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 gebruikersverhaal?

“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 dient als aanleiding voor een gesprek, niet als een formulier dat moet worden ingevuld. Het invullen van de lege velden is het begin van de verfijning.

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 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 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 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.” 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 u dit opdringt aan platformwerk, bekende bugs of onderzoekspieken, leidt dit tot zinnen die alleen maar omhaal 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-schatting: de complete gids: hier vindt u alle informatie hierover.
• Wat is een user story?: de redenen achter het sjabloon, de drie C’s en INVEST.
• Voorbeelden van gebruikersverhalen: zestien verhalen met toelichting waarmee u uw eigen verhalen kunt toetsen.
• Acceptatiecriteria: hoe stelt u deze op?: 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.