
Er bestaat vaak verwarring over de termen DoD: The Definition of Done en Acceptatiecriteria. Hoewel beide concepten belangrijk zijn voor het leveren van kwalitatieve hoogwaardige producten, verschillen ze in doel, scope en toepassing. Hierbij een duidelijke uitleg over beide begrippen, inclusief de belangrijkste verschillen en hoe ze bijdragen aan een succesvolle productontwikkeling.
Definition of Done (DoD)
De Definition of Done is een overeengekomen set van criteria die bepaalt wanneer een werkitem – zoals een user story, feature of productincrement – als volledig en afgerond wordt beschouwd. Het biedt een uniforme standaard waaraan elk opgeleverd werk moet voldoen en is van toepassing op alle user stories binnen het team.
De DoD helpt om verwachtingen te standaardiseren en voorkomt dat werk voortijdig als “afgerond/done” wordt beschouwd. Dit draagt bij aan de kwaliteit, transparantie en voorspelbaarheid van het ontwikkelproces.
Waarom is de DoD belangrijk?
- Zorgt voor uniformiteit binnen het team.
- Helpt bij het handhaven van kwaliteit en voorkomt onvoltooide of ongeteste functionaliteiten.
- Maakt transparantie en gedeelde verwachtingen mogelijk binnen het team en met stakeholders.
- Faciliteert een soepeler releaseproces, doordat alles voldoet aan een minimumstandaard.
Voorbeelden van DoD-criteria
- Code is geschreven volgens de afgesproken standaarden en is gereviewd door ten minste één teamlid.
- Alle unit- en integratietests zijn geschreven en geslaagd.
- De code is gedeployed naar een testomgeving en gevalideerd.
- Functionele en technische documentatie is bijgewerkt.
- De nieuwe functionaliteit is met succes gedemonstreerd aan stakeholders.
- Er zijn geen openstaande kritische bugs of blockers.
Belangrijk: De Definition of Done is een levend document en kan evolueren naarmate het team groeit en volwassen wordt.
Acceptatiecriteria
Acceptatiecriteria zijn specifieke voorwaarden en vereisten waaraan een user story of feature moet voldoen om te worden geaccepteerd door de product owner en de stakeholders. In tegenstelling tot de DoD, die generiek en op alle user stories van toepassing is, zijn acceptatiecriteria uniek voor elke user story en beschrijven ze wat er exact moet worden gebouwd en getest.
Waarom zijn acceptatiecriteria belangrijk?
- Zorgen voor helderheid: Ze helpen bij het afbakenen van de scope van een user story.
- Vermijden van misverstanden: Door duidelijke verwachtingen vast te leggen, wordt voorkomen dat er verschillende interpretaties bestaan.
- Begeleiding voor ontwikkeling en testen: Acceptatiecriteria dienen als leidraad voor zowel ontwikkelaars als testers om te verifiëren of een feature aan de eisen voldoet.
- Bepalen van de “Definition of Ready”: Een user story zonder duidelijke acceptatiecriteria wordt vaak als niet klaar voor ontwikkeling beschouwd.
Voorbeelden van acceptatiecriteria:
Voor een user story zoals: “Als gebruiker wil ik kunnen inloggen met mijn account zodat ik toegang krijg tot mijn dashboard.”
- De gebruiker kan succesvol inloggen met een correcte gebruikersnaam en wachtwoord.
- Het systeem toont een foutmelding bij een onjuiste inlogcombinatie.
- Na drie mislukte inlogpogingen wordt het account tijdelijk geblokkeerd.
- De gebruiker ontvangt een bevestigingsmail na een succesvolle login vanaf een nieuw apparaat.
Tip: Gebruik het “Given-When-Then” format (uit BDD – Behavior Driven Development) voor nog meer helderheid:
Given | de gebruiker bevindt zich op de loginpagina, |
---|---|
When | hij zijn gebruikersnaam en wachtwoord correct invoert, |
Then | krijgt hij toegang tot het dashboard. |
Belangrijkste verschillen tussen DoD en Acceptatiecriteria
Kenmerk | Definition of Done (DoD) | Acceptatiecriteria |
---|---|---|
Toepassing | Van toepassing op alle user stories | Specifiek voor een individuele user story |
Doel | Zorgen voor consistente kwaliteit | Definiëren wanneer een story voldoet aan de functionele eisen |
Eigenaarschap | Het hele team | Product Owner in samenwerking met het team |
Focus | Proces- en kwaliteitsstandaarden | Functionele en niet-functionele eisen |
Scope | Overkoepelend voor het gehele project | Uniek voor een specifieke user story |
Veelvoorkomende misverstanden
- “Als de acceptatiecriteria zijn behaald, is de user story klaar.”
- Niet per se. Acceptatiecriteria richten zich op de functionele eisen, maar zonder te voldoen aan de DoD (zoals code reviews, tests, documentatie) is de story niet volledig afgerond.
- “De DoD is alleen voor ontwikkelaars.”
- Onjuist. De DoD geldt voor het hele team, inclusief testers, analisten en product owners, en omvat vaak ook zaken zoals documentatie en stakeholdervalidatie.
- “We hebben geen DoD nodig als we duidelijke acceptatiecriteria hebben.”
- Acceptatiecriteria specificeren alleen de eisen per story, terwijl de DoD ervoor zorgt dat álle stories aan bredere kwaliteitsstandaarden voldoen.