Acceptatiecriteria: Wanneer is een User Story écht‘ af’?

Een User Story zonder acceptatiecriteria is als een route zonder eindbestemming. Het team weet niet precies wat er verwacht wordt, er ontstaan misverstanden en het risico op rework neemt toe. Acceptatiecriteria helpen teams om te bepalen wanneer een Story écht klaar is en voldoen aan de verwachtingen van de gebruiker.

Maar hoe schrijf je goede acceptatiecriteria? En hoe zorg je ervoor dat ze waarde toevoegen in plaats van extra bureaucratie?

‍

Wat zijn acceptatiecriteria?

Acceptatiecriteria zijn de voorwaarden waaraan een User Story of backlog-item moet voldoen om als ‘Done’ te worden beschouwd. Ze helpen om:

• Verwachtingen tussen Product Owner, team en stakeholders op één lijn te krijgen.
• Objectief te bepalen wanneer een functionaliteit voldoet.
• Testen en validatie eenvoudiger en efficiënter te maken.

Voorbeeld User Story:

"Als gebruiker wil ik een nieuw wachtwoord kunnen instellen, zodat ik weer toegang heb tot mijn account."

Goede acceptatiecriteria:

• Gebruiker ontvangt een e-mail met een resetlink na het aanvragen van een nieuw wachtwoord.
• De link is 24 uur geldig en vervalt daarna.
• Gebruiker moet een nieuw wachtwoord invoeren dat voldoet aan de beveiligingsregels.
• Bij een succesvol nieuw wachtwoord krijgt de gebruiker een bevestigingsmelding.

‍

Zonder deze criteria blijft het vaag wat precies nodig is.

‍

Hoe schrijf je goede acceptatiecriteria?

‍

‍1. Maak ze specifiek en meetbaar

Slecht: "De functionaliteit moet goed werken."

Goed: "De gebruiker moet binnen 3 seconden een zoekresultaat krijgen."

‍

‍2. Gebruik de ‘Given-When-Then’-methode

Een veelgebruikte structuur uit Behaviour-Driven Development (BDD) die helpt bij het helder formuleren van criteria:

• Given (situatie vooraf)
• When (actie van de gebruiker)
• Then (verwacht resultaat)

‍

Voorbeeld:

User Story:

"Als gebruiker wil ik mijn profiel kunnen bewerken, zodat mijn gegevens altijd up-to-date zijn."

Acceptatiecriteria:

• Given de gebruiker is ingelogd, when hij naar het profielscherm gaat, then ziet hij een knop ‘Bewerken’.
• Given de gebruiker wijzigt zijn e-mailadres, when hij op ‘Opslaan’ klikt, then ontvangt hij een bevestigingsmail.
• Given de gebruiker voert een ongeldig telefoonnummer in, when hij op ‘Opslaan’ klikt, then verschijnt een foutmelding.

Door deze structuur is het voor zowel ontwikkelaars als testers meteen duidelijk hoe de functionaliteit zou moeten werken.

‍

Acceptatiecriteria VS. Definition of Done

Deze twee termen worden soms door elkaar gehaald, maar ze hebben een andere functie:

‍

‍Acceptatiecriteria

Specifiek voor één User Story

Richt zich op functionele eisen

Bepaalt of een Story voldoet aan de verwachtingen van de gebruiker

‍

Definition of Done (DoD)

Geldt voor alle Stories in het team

Richt zich op kwaliteitsnormen en technische afwerking

Bepaalt of een Story voldoet aan de algemene teamstandaarden

‍

Voorbeeld Definition of Done:

• Code is gereviewd door een teamgenoot.
• Er zijn geen bekende bugs meer.
• Functionaliteit is getest en werkt zoals beschreven in de acceptatiecriteria.
• Beide zijn nodig voor een succesvolle oplevering.

‍

Praktische tips voor betere acceptatiecriteria

• Schrijf ze samen – Betrek de Product Owner, het team en (indien mogelijk) testers.
• Denk aan negatieve scenario’s – Wat gebeurt er bij een foutieve invoer? Wat als de internetverbinding wegvalt?
• Hou het kort en to-the-point – Geen lange lappen tekst, maar heldere statements.
• Gebruik voorbeelden – Dit maakt het makkelijker te begrijpen en te testen.
  ‍

‍