Acceptatiecriteria: hoe stelt u deze op?

Acceptatiecriteria vormen de goed/fout-toets voor een story en worden opgesteld voordat met de werkzaamheden wordt begonnen — de formaten die geschikt zijn, uitgewerkte voorbeelden en hoe deze verschillen van de definitie van ‘klaar’.

Acceptatiecriteria zijn de voorwaarden waaraan een story moet voldoen om te worden geaccepteerd — een test waarbij men slaagt of zakt, die wordt opgesteld voordat iemand begint met programmeren. Er is geen sprake van gedeeltelijke voldoening: aan elk criterium wordt voldaan of niet. Ze beschrijven wat het resultaat moet doen, niet hoe het moet worden gebouwd. En het zijn testcriteria, geen tweede beschrijving van de functie. Als u eraan kunt voldoen met code die het probleem niet oplost, zijn het geen acceptatiecriteria — het zijn verkapte vereisten.

Elk verhaal bevat een impliciete vraag: hoe weten we wanneer het af is? Acceptatiecriteria geven daar al vóór aanvang van het werk een duidelijk antwoord op. Als u deze goed opstelt, wordt het maken van een schatting eenvoudiger, schrijft de demo zich als vanzelf en is ‘klaar’ geen onderhandelingspunt meer. Als u ze vaag houdt, levert u een functie op waarover niemand het eens was.

Wat acceptatiecriteria zijn, en wat ze niet zijn

Een goed acceptatiecriterium is iets dat u aan een tester zou kunnen geven die nooit bij uw verfijningsbijeenkomst aanwezig is geweest, en die dan precies zou weten wat hij of zij moet controleren. Het beschrijft een resultaat dat de gebruiker kan waarnemen, niet de implementatie die dit resultaat oplevert. „Gebruik een Redis-cache” is geen acceptatiecriterium — het is een oplossing. “De resultaten worden binnen een seconde geladen voor een tabel met 10.000 rijen” is dat wel, omdat iedereen dit kan testen en niemand daarvoor de code hoeft te lezen.

Het is ook geen verlanglijstje. Elk criterium moet toetsbaar zijn. Als een uitspraak niet kan worden gecontroleerd — „de pagina is intuïtief”, „de prestaties zijn goed” — dan is het geen criterium, maar een wens. Schrap het of maak het meetbaar.

De twee formaten die goed werken

Gebruik Given/When/Then voor gedrag dat afhankelijk is van de toestand, en een gewone checklist voor een reeks onafhankelijke vereisten. De meeste teams grijpen voor alles naar Given/When/Then; laat u daar niet toe verleiden. Een checklist is sneller te lezen en moeilijker op te smukken wanneer het verhaal simpelweg luidt: „deze vijf dingen moeten van toepassing zijn.”

Gegeven / Wanneer / Dan

Uitgaande van een begintoestand: wanneer de gebruiker iets doet, reageert het systeem op een specifieke manier. Deze opzet bewijst zijn nut doordat u gedwongen wordt alle drie de elementen te benoemen — de voorwaarde, de trigger en het waarneembare resultaat — en dat is precies wat bij een vaag criterium buiten beschouwing blijft.

Voorbeelden van acceptatiecriteria

Een inlogverhaal, geschreven volgens het Given/When/Then-model:

  • Als een geregistreerde gebruiker zich op de inlogpagina bevindt, wanneer hij of zij een correct e-mailadres en wachtwoord invoert, dan komt hij of zij op het dashboard terecht.
  • Als een geregistreerde gebruiker drie keer een verkeerd wachtwoord invoert, dan wordt het account gedurende 15 minuten geblokkeerd en wordt aan de gebruiker getoond hoeveel tijd er nog resteert.
  • Als de inlogpagina wordt weergegeven, wanneer het e-mailveld leeg is, dan is de verzendknop uitgeschakeld.

Een verhaal over „het filteren van de resultatentabel”, opgesteld in de vorm van een checklist:

  • Het filter wordt toegepast zodra u een selectie maakt — er is geen aparte knop ‘Toepassen’.
  • Twee filters worden met „EN“ gecombineerd, niet met „OF“.
  • Als u alle filters wist, wordt de volledige, ongesorteerde lijst weergegeven.
  • Een lege resultatenset geeft de status „geen overeenkomsten“ weer, en niet een lege tabel.

Let op wat in beide gevallen wordt weggelaten: de database, het framework en de namen van de componenten. Ze geven aan wat de gebruiker te zien krijgt, niet hoe u dit gaat realiseren — en elke regel is een onderdeel dat een tester kan goedkeuren of afkeuren zonder u daar vragen over te stellen.

Hoe schrijft u acceptatiecriteria?

  • Schrijf ze tijdens backlogverfijning, samen met het team — niet alleen, achteraf.
  • Eén waarneembaar resultaat per regel. Als er in een regel een „en“ staat die daadwerkelijk een rol speelt, gaat het om twee criteria.
  • Noem het ‘unhappy path’. De lege status, de time-out, de onjuiste invoer — daar schuilt de inspanning.
  • Laat ze betrekking hebben op het gedrag, niet op het ontwerp. De mock-up heeft betrekking op de lay-out; de criteria hebben betrekking op wat er moet gebeuren.
  • Stop bij ongeveer vijf.

Hoeveel acceptatiecriteria zijn er te veel?

Ongeveer vijf. Niet omdat er een regel is, maar omdat een verhaal dat tien afzonderlijke, toetsbare voorwaarden vereist, tien afzonderlijke waarde-elementen bevat — wat betekent dat het in feite meerdere verhalen zijn die zich voordoen als één. Wanneer de lijst te lang wordt, vormen de acceptatiecriteria juist de scheidslijn.

Indeling op basis van acceptatiecriteria

Als een verhaal meer dan vijf acceptatiecriteria bevat, vormen die criteria doorgaans de onderverdeling. De lijst is een backlog die als checklist fungeert.

Acceptatiecriteria zijn bedoeld om een story te beschrijven. Ze zijn niet bedoeld om de story zelf te zijn. Wanneer de lijst lang wordt — zes, acht, tien punten — heeft het team het opsplitsen vaak al gedaan zonder dat het zich daarvan bewust is. Elk criterium is een klein onderdeel dat het team zou kunnen opleveren, demonstreren en vervolgens achter zich laten. Door de hele lijst als één enkele verbintenis te beschouwen, wordt het team gedwongen om alles in één keer op zich te nemen, wat de slechtst mogelijke combinatie is van omvang en risico die u iemand in een sprint kunt opleggen.

Om dit te onderscheiden, neemt u elk criterium afzonderlijk en stelt u de vraag die u bij elke user story zou stellen: zou het team dit op zichzelf uitbrengen? Zou de gebruiker er op zichzelf baat bij hebben? Kan er een demo van worden gegeven? De punten die deze toets doorstaan, zijn user stories. De punten die deze toets niet doorstaan, behoren doorgaans tot een van de overgebleven stories — het betreft onderdelen van een story die u al hebt afgesplitst, en geen op zichzelf staand werk.

Waar dit tekortschiet, is bij nauw met elkaar verbonden criteria — „het formulier valideert de invoer en slaat deze op in de database en toont een bevestiging.” Deze drie lijken weliswaar op te splitsen, maar de gebruiker heeft er niets aan als er slechts één wordt opgeleverd. Dit is niet op te splitsen per criterium; het is één enkel, klein verhaal, en de opsommingstekens geven alleen maar aan dat het team grondig te werk gaat.

Acceptatiecriteria versus vereisten

Een vereiste geeft aan wat er moet worden gebouwd. Een acceptatiecriterium geeft aan hoe u weet of u het juiste hebt gebouwd. „Gebruikers kunnen hun wachtwoord opnieuw instellen” is een vereiste — en u kunt hieraan voldoen met een proces dat zo gebrekkig is dat niemand het voltooit. „Een gebruiker die een reset aanvraagt, ontvangt binnen twee minuten een e-mail waarvan de link na één uur verloopt” is een acceptatiecriterium, omdat het een test is waarvoor het gebrekkige proces niet voldoet. Vereisten bakenen het werk af; criteria zorgen ervoor dat het wordt goedgekeurd.

Acceptatiecriteria versus de definitie van ‘klaar’

Deze worden voortdurend door elkaar gehaald, terwijl het onderscheid eenvoudig is: acceptatiecriteria gelden per verhaal; de definitie van ‘klaar’ is algemeen. De bovenstaande criteria beschrijven wat het inlogverhaal specifiek moet doen. De definitie van ‘klaar’ — getest, code-reviewed, gedocumenteerd, geïmplementeerd in de staging-omgeving — geldt voor elk verhaal dat het team oplevert. Een verhaal kan aan de acceptatiecriteria voldoen en toch nog niet ‘klaar’ zijn, omdat ‘werkt zoals gespecificeerd’ en ‘klaar voor release’ verschillende drempels zijn. U hebt beide nodig.

Storypoints versus acceptatiecriteria

Acceptatiecriteria beschrijven het eindresultaat — wat er moet zijn vervuld om het verhaal als opgeleverd te beschouwen. Story points beschrijven het traject — hoe omvangrijk het werk is tussen „we hebben dit nog niet“ en „aan de criteria is voldaan“. Twee verschillende assen. Als men deze door elkaar haalt, leidt dat tot criteria met een bepaalde omvang, wat zinloos is, of tot puntschattingen zonder onderliggende criteria, wat wishful thinking is.

Heeft het toevoegen van een criterium invloed op de schatting? Soms wel. Een criterium dat verborgen werk aan het licht brengt — „moet toegankelijk zijn voor schermlezers“ — heeft doorgaans wel invloed, omdat het een inspanning benoemt die voorheen impliciet was. Een criterium dat slechts een bestaande aanname verduidelijkt — „moet werken in Chrome en Safari“ terwijl dat altijd al de ondersteunde browsers waren — zou geen invloed moeten hebben. De volgorde is van belang: eerst de criteria, daarna de punten. Een schatting maken voordat de criteria duidelijk zijn, is schatten vóór verfijning, en dit is de meest voorkomende oorzaak van grote verschillen in stemmen.

Schrijf de test voordat u aan het werk gaat. Als een criterium niet kan mislukken, is het geen criterium — en als u er meer dan vijf hebt, hebt u waarschijnlijk te maken met meer dan één user story.

Veelgestelde vragen

Wat zijn acceptatiecriteria?

Acceptatiecriteria zijn de voorwaarden waaraan een story moet voldoen om te worden goedgekeurd — een goed/fout-toets die wordt opgesteld voordat met het werk wordt begonnen. Ze beschrijven wat het resultaat moet doen, niet hoe het moet worden gebouwd, en er is geen sprake van gedeeltelijke goedkeuring: aan elk criterium wordt voldaan of niet.

Hoe stelt u acceptatiecriteria op?

Schrijf elk item zo op dat u het zou kunnen overhandigen aan een tester die het verhaal nog nooit heeft gezien. Gebruik „Given/When/Then” voor gedrag dat afhankelijk is van de toestand, of een eenvoudige checklist voor een reeks onafhankelijke vereisten. Zorg ervoor dat ze testbaar blijven, richt u op de resultaten en beperk het aantal tot ongeveer vijf — bij meer dan dat gaat het al om meerdere verhalen.

Wat is het verschil tussen acceptatiecriteria en vereisten?

Vereisten geven aan wat er moet worden gebouwd; acceptatiecriteria geven aan hoe u kunt vaststellen of het goed is. Aan een vereiste kan worden voldaan door code die de kern van de zaak mist. Een acceptatiecriterium is een test — als deze slaagt, is dat deel van het verhaal afgerond; als u de test kunt doorstaan zonder het probleem van de gebruiker op te lossen, is het in feite een vermomde vereiste.

Wat is het verschil tussen acceptatiecriteria en de definitie van ‘klaar’?

Acceptatiecriteria gelden per story — ze beschrijven wat deze specifieke story moet doen. De definitie van ‘klaar’ is één algemene checklist die voor elke story geldt (getest, beoordeeld, gedocumenteerd, geïmplementeerd). Een story kan aan de acceptatiecriteria voldoen en toch nog niet ‘klaar’ zijn als deze de teambrede gate niet doorloopt.

Wie stelt de acceptatiecriteria op?

De producteigenaar is hiervoor verantwoordelijk, maar ze worden tijdens de verfijning samen met het team opgesteld. De producteigenaar bepaalt de doelstelling; de ontwikkelaars en testers brengen de randgevallen aan het licht. Acceptatiecriteria die achteraf in je eentje worden opgesteld, zijn juist de criteria waarbij het geval over het hoofd wordt gezien dat in de productieomgeving tot fouten leidt.

Aanbevolen lectuur