Effectieve acceptatiecriteria schrijven: duidelijkheid vóór ontwikkeling begint

Wat zijn goede acceptatiecriteria?

Acceptatiecriteria beschrijven de voorwaarden waaraan een User Story of backlogitem moet voldoen om als ‘Done’ te worden beschouwd. Ze zijn bondig, helder en testbaar, zodat het team én de Product Owner exact weten wanneer een story klaar is. Goed geformuleerde criteria voorkomen misverstanden, verminderen herwerk en vormen de basis voor testscenario’s.

‍

Voorbeelden van goede acceptatiecriteria

• Duidelijk: “Wanneer ik op de ‘Bestel’-knop klik, ontvang ik binnen 1 minuut een bevestigingsmail met een samenvatting van mijn bestelling.”
• Testbaar: “Als ik een geldige kortingscode invoer, wordt 10% korting toegepast op het totaalbedrag, en dit is zichtbaar in de kassa.”

‍

Wie bepaalt acceptatiecriteria? (Rol van PO en team)

De Product Owner is verantwoordelijk voor de inhoud en waarde van het backlogitem, dus hij/zij stelt vaak de eerste versie van de acceptatiecriteria op. Toch is het ideale scenario dat de PO en het ontwikkelteam samen overleggen. Het team kan immers aangeven welke criteria technisch haalbaar zijn en welke edge cases relevant zijn. Zo ontstaat een gezamenlijke definitie van ‘klaar’.

‍

Valkuilen bij acceptatiecriteria voorkomen

• Te vaag of te breed: “Gebruiker moet kunnen registreren.” Maar hoe? Wat zijn de velden? Wat is de validatie?
• Te technisch: “Database schema moet worden geüpdatet.” Dit kan een interne taak zijn, maar zegt weinig over klantwaarde.
• Geen edge cases: “Wat gebeurt er als de gebruiker een ongeldig e-mailadres invult of zijn verbinding verliest?”
• Geen duidelijke testmethode: Zonder meetbare voorwaarde is het lastig om te toetsen of de story echt ‘Done’ is.

‍

Veelgemaakte fouten bij acceptatiecriteria

1. Geen realistisch scenario: Criteria die geen rekening houden met wat er in werkelijkheid kan gebeuren (bv. spaties, speciale tekens, netwerkuitval).
2. Copy-paste criteria: Elk item dezelfde criteria geeft geen relevante info.
3. Pas laat besproken: Criteria die pas tijdens de sprint naar voren komen, kunnen vertraging veroorzaken.
4. Geen consensus: Als de PO en het team acceptatiecriteria niet samen doornemen, ligt misinterpretatie op de loer.

‍

Checklists en templates voor heldere acceptatiecriteria

Een praktisch format is om elk criterium te beschrijven als Given, When, Then:

• Given: De beginsituatie (bijv. “Gebruiker is ingelogd en staat op de kassapagina”).
• When: De actie (“Gebruiker klikt op ‘Betaal met iDEAL’”).
• Then: De verwachte uitkomst (“Gebruiker ziet een bevestigingspagina met ordernummer en betaalstatus”).

‍

Praktisch voorbeeld

Criterium 1: “Given ik ben op de afrekenpagina, when ik een geldige kortingscode invoer, then zie ik direct de verlaagde totaalprijs met X% korting.”

‍

Conclusie

Acceptatiecriteria brengen focus en duidelijkheid in je User Stories. Ze helpen het team om te begrijpen wanneer iets echt ‘af’ is en voorkomen dubbelzinnigheid. Door criteria samen te bespreken, goede scenario’s uit te werken en meetbare voorwaarden te formuleren, werk je stap voor stap aan een product dat voldoet aan de wensen van de klant. Vergeet niet dat acceptatiecriteria evolueren—houd ze actueel en blijf ze bespreken in refinement- en planningssessies.