📋 Definition of Done (DoD)
📖 Introductie
Binnen softwareontwikkeling is het essentieel om een eenduidige definitie te hebben van wanneer werk daadwerkelijk “af” is.
Zonder duidelijke afspraken ontstaan:
- discussies over oplevering
- inconsistente kwaliteit
- incomplete functionaliteit
- problemen tijdens test en release
👉 De Definition of Done (DoD) biedt een gezamenlijke afspraak over wanneer werk als afgerond wordt beschouwd.
👉 De DoD is een set van minimale kwaliteitscriteria waaraan elke oplevering moet voldoen voordat deze als “done” wordt beschouwd.
Wat is Definition of Done?
De Definition of Done is een gedeelde checklist die bepaalt wanneer een work item:
- volledig is geïmplementeerd
- voldoet aan kwaliteitsnormen
- gereed is voor release
👉 Het is een teamafspraak over wat “af” betekent binnen de delivery lifecycle.
🔹 Belangrijk principe
👉 Werk is niet done zolang het niet voldoet aan de Definition of Done.
👉 Werk dat niet voldoet aan de DoD:
- mag niet worden gereleased
- mag niet als afgerond worden beschouwd
- kan niet als “complete increment” worden gepresenteerd
Doel van Definition of Done
De DoD zorgt voor:
- consistente kwaliteit
- transparantie binnen het team
- voorspelbare oplevering
- minder rework
- eenduidige verwachtingen over “af”
👉 Zonder DoD verschilt de interpretatie van “done” per teamlid.
Scope van Definition of Done
🔹 Geldt voor alle work items
De DoD geldt voor:
- user stories
- features
- bugs
- technische taken (indien relevant)
👉 De DoD is generiek en herbruikbaar over alle backlog items heen.
🔹 Verschil met Acceptance Criteria
| Onderdeel |
Definition of Done |
Acceptance Criteria |
| Scope |
Alle work items |
Per work item |
| Focus |
Kwaliteit & afronding |
Functionaliteit |
| Vraag |
“Is dit werk klaar?” |
“Doet het wat bedoeld is?” |
👉 Beide zijn nodig om werk correct op te leveren.
Typische inhoud van een DoD
Een DoD bevat minimale, toetsbare kwaliteitscriteria.
🔹 Code & Development
- code voldoet aan coding standards
- code is gereviewd (peer review)
- geen kritieke code smells of warnings
🔹 Testing
- unit tests zijn geschreven en geslaagd
- integratie testen zijn uitgevoerd
- geen open critical bugs
🔹 Functionaliteit
- alle acceptance criteria zijn behaald
- functionaliteit werkt zoals ontworpen
🔹 Documentatie
- technische documentatie is bijgewerkt
- relevante wijzigingen zijn vastgelegd
- indien nodig: gebruikersdocumentatie aangepast
🔹 Release readiness
- work item is succesvol getest in testomgeving
- geen regressies geïntroduceerd
- klaar voor release naar volgende omgeving
👉 Het resultaat is een increment dat kwaliteit en stabiliteit borgt binnen de ALM-cyclus.
Gebruik binnen ALM
📋 Plan & Track
- ondersteunt backlog refinement
- definieert kwaliteitsverwachtingen vooraf
💻 Develop
- stuurt implementatie en coding standards
🧪 Test
- vormt basis voor testvalidatie
🚀 Release
- bepaalt of werk release-ready is
👉 De DoD is een quality gate door de volledige delivery lifecycle.
Lifecycle en beheer
🔹 Gezamenlijk opgesteld
De DoD wordt bepaald door:
- developers
- testers
- product owner
- architect (indien nodig)
🔹 Evolueert over tijd
- wordt aangescherpt op basis van ervaring
- groeit mee met teamvolwassenheid
👉 De DoD is een levend kwaliteitskader.
🔹 Toepassing in ceremonies
- Sprint Planning → check op haalbaarheid
- Daily → voortgang richting DoD
- Review → alleen “done” werk wordt getoond
- Retro → verbeteren van DoD
Best practices
- maak criteria concreet en meetbaar
- houd DoD klein maar streng
- gebruik één gezamenlijke DoD per team
- pas DoD regelmatig aan
- integreer DoD in DevOps proces
Veelgemaakte fouten
- vage criteria (“getest”)
- DoD verwarren met acceptance criteria
- DoD niet actief gebruiken
- te uitgebreide of bureaucratische DoD
- DoD niet onderhouden