Een personage in de vorm van een plakbriefje dat een checklist vasthoudt waarop één regel is aangevinkt en één is doorgehaald, en deze vergelijkt met een voltooide tekening op een whiteboard.

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 user story moet voldoen om te worden geaccepteerd: een test waarbij wordt bepaald of het voldoet of niet, die wordt opgesteld voordat iemand begint met programmeren. Er is geen sprake van gedeeltelijke goedkeuring: 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 aan deze criteria 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 verfijningsvergadering 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 in minder dan 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 punt niet kan worden gecontroleerd („de pagina is intuïtief”, „de prestaties zijn goed”), is het geen criterium, maar een wens. Schrap het dan 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.”

Aangezien / 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 wordt gelaten.

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 weergegeven hoe lang de blokkering nog duurt.
  • Als de inlogpagina wordt weergegeven, wanneer het e-mailveld leeg is, dan is de verzendknop uitgeschakeld.

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

  • Het filter wordt bij selectie toegepast; 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?

  • Stel ze op tijdens de verfijning van de backlog, samen met het team, en niet achteraf in uw eentje.
  • Eén waarneembaar resultaat per regel. Indien een regel een „en“ bevat die daadwerkelijk een rol speelt, gaat het om twee criteria.
  • Noem het ‘unhappy path’. De lege toestand, 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 uit meerdere verhalen bestaat die zich voordoen als één geheel. Wanneer de lijst te lang wordt, vormen de acceptatiecriteria zelf de scheidslijn.

Indeling op basis van acceptatiecriteria

Als een verhaal meer dan vijf acceptatiecriteria bevat, vormen die criteria doorgaans de afbakening. 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 gehele 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 onder de loep en stelt u de vraag die u bij elke user story zou stellen: zou het team dit op zichzelf kunnen opleveren? Zou de gebruiker er op zichzelf baat bij hebben? Kan er een demonstratie 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 werkstroom die zo gebrekkig is dat niemand deze 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 de gebrekkige werkstroom niet voldoet. Vereisten bakenen het werk af; criteria vormen de toetssteen.

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) is van toepassing op 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. Storypunten beschrijven het traject: hoe omvangrijk het werk is tussen „dit hebben we nog niet” en „aan de criteria is voldaan”. Twee verschillende assen. Door deze te vermengen ontstaan er criteria met een omvangsaanduiding, wat zinloos is, of puntschattingen zonder onderliggende criteria, wat wishful thinking is.

Heeft het toevoegen van een criterium invloed op de schatting? Soms. Een criterium dat verborgen werk aan het licht brengt („moet toegankelijk zijn voor schermlezers”) heeft dat meestal wel, omdat het inspanningen benoemt die voorheen impliciet waren. Een criterium dat slechts een bestaande aanname verduidelijkt („moet werken in Chrome en Safari”, terwijl dat altijd al de ondersteunde browsers waren) zou dat niet moeten doen. De volgorde is van belang: eerst de criteria, daarna de punten. Een schatting maken voordat de criteria duidelijk zijn, komt neer op schatten vóór verfijning, en dit is de meest voorkomende oorzaak van wijdverspreide 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 meer dan één user story.

Veelgestelde vragen

Wat zijn acceptatiecriteria?

Acceptatiecriteria zijn de voorwaarden waaraan een user story moet voldoen om te worden goedgekeurd: een goed/fout-test die wordt opgesteld voordat met het werk wordt begonnen. Zij 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 vijf hebt u te maken met 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 de test slaagt, is dat deel van het verhaal voltooid; als u de test kunt doorstaan zonder het probleem van de gebruiker op te lossen, is het in feite een verkapte vereiste.

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

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

Wie stelt de acceptatiecriteria op?

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

Aanbevolen lectuur