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 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 aan de 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 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 falsifieerbaar 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 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 wordt 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 gecombineerd met ‘EN’, 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. Er wordt aangegeven 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 daarover vragen te stellen.

Hoe schrijft u acceptatiecriteria?

  • Schrijf ze tijdens backlogverfijning, samen met het team, en niet achteraf in uw eentje.
  • Eén waarneembaar resultaat per regel. Als er in een regel een „en“ staat die daadwerkelijk een rol speelt, zijn er 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 meerdere verhalen zijn die zich voordoen als één. Wanneer de lijst te lang wordt, vormen de acceptatiecriteria zelf de scheidslijn.

Indeling op basis van acceptatiecriteria

Indien een verhaal meer dan vijf acceptatiecriteria bevat, vormen deze criteria doorgaans de indeling. 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 vaak al ongemerkt het werk opgedeeld. 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 op te splitsen, 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? Zou er een demonstratie van kunnen worden gegeven? De punten die deze toets doorstaan, zijn verhalen. De punten die deze toets niet doorstaan, behoren doorgaans tot een van de overgebleven stories: het gaat om onderdelen van een story die u al hebt afgesplitst, en niet om 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 wachtwoordreset aanvraagt, ontvangt binnen twee minuten een e-mail met een link die na één uur verloopt” is een acceptatiecriterium, omdat het een test is waarvoor het gebrekkige proces 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. Story points beschrijven het traject: hoe omvangrijk het werk is tussen „dit hebben we nog niet” en „aan de criteria is voldaan”. Twee verschillende assen. Het door elkaar halen ervan leidt 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. Een criterium dat verborgen werk aan het licht brengt („moet toegankelijk zijn voor schermlezers”) heeft doorgaans wel invloed, 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 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 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 verhaal.

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 de werkzaamheden wordt begonnen. Zij beschrijven wat het resultaat moet doen, niet hoe het moet worden gebouwd, en er is geen sprake van gedeeltelijke waardering: 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 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 deze 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 vermomde 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 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 teamwijde 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 geeft de kaders aan voor het eindresultaat; de ontwikkelaars en testers brengen de randgevallen aan het licht. Acceptatiecriteria die achteraf in eenzaamheid worden opgesteld, zijn juist de criteria waarbij het geval over het hoofd wordt gezien dat in de productieomgeving tot fouten leidt.

Aanbevolen lectuur