Introductie
Binnen softwareontwikkeling is het essentieel om een eenduidige definitie te hebben van wanneer werk “af” is.
Zonder duidelijke afspraken ontstaan:
- discussies over oplevering
- inconsistentie in kwaliteit
- incomplete functionaliteit
- onverwachte issues tijdens testing of deployment
👉 De Definition of Done (DoD) is een gezamenlijke afspraak binnen het team over wanneer werk voldoet aan alle kwaliteits- en oplevercriteria.
👉 De DoD fungeert als een quality gate binnen de gehele lifecycle en CI/CD pipelines.
1. Wat is Definition of Done
De Definition of Done is een gedeelde checklist die bepaalt wanneer een work item:
- compleet is
- voldoet aan kwaliteitsnormen
- klaar is voor oplevering of deployment
👉 Het is een gezamenlijke afspraak binnen het team over wat “done” betekent.
🔹 Belangrijk principe
👉 Werk is niet done als het niet voldoet aan de Definition of Done.
👉 Werk dat niet voldoet mag niet beschouwd worden als afgerond of gereed voor release.
2. Doel van Definition of Done
- ✅ consistente kwaliteit
- ✅ transparantie binnen het team
- ✅ minder ambiguïteit
- ✅ voorspelbare oplevering
- ✅ minder rework
3. Scope van Definition of Done
🔹 Geldt voor ALLE work items
- user stories
- features
- taken en bugs
👉 Het is generiek en herbruikbaar (in tegenstelling tot acceptance criteria).
🔹 Verschil met Acceptance Criteria
| Onderdeel |
Definition of Done |
Acceptance Criteria |
| Scope |
Voor alle work items |
Per item |
| Focus |
Kwaliteit & completion |
Functionaliteit |
| Doel |
“Is dit werk klaar?” |
“Doet het wat het moet doen?” |
4. Typische inhoud van een DoD
🔹 Code & Development
- code voldoet aan standaarden
- code is gereviewed (peer review)
- geen kritische issues of warnings aanwezig
🔹 Testing
- unit tests uitgevoerd en geslaagd
- integratietests uitgevoerd
- relevante test levels toegepast (bijv. E2E waar nodig)
- geen blocking bugs aanwezig
🔹 Functionaliteit
- alle acceptance criteria zijn behaald
- functionaliteit werkt zoals bedoeld
🔹 Documentatie
- technische documentatie bijgewerkt
- gebruikersdocumentatie bijgewerkt
- relevante wijzigingen vastgelegd
🔹 Deployment readiness
- oplossing is gedeployed naar testomgeving
- validatie uitgevoerd (bijv. smoke tests)
- geen regressies vastgesteld
👉 Het resultaat moet deployable en bruikbaar zijn.
5. Gebruik binnen de lifecycle
De Definition of Done wordt toegepast binnen meerdere fases van de software lifecycle.
- Plan & Track → refinement en planning
- Develop → kwaliteitsborging tijdens development
- Build & Test → validatie van kwaliteit
- Deploy → bepalen of iets release-ready is
👉 De DoD is een kwaliteitscontrole over de gehele lifecycle.
6. Lifecycle en beheer
🔹 Gezamenlijk opgesteld
- developers
- testers
- product owner
- architect (optioneel)
🔹 Evolueert over tijd
- wordt aangepast op basis van learnings
- groeit mee met volwassenheid van het team
👉 De DoD is een levend document.
7. Best practices
- maak DoD concreet en meetbaar
- houd criteria objectief toetsbaar
- zorg dat iedereen het begrijpt
- gebruik één gezamenlijke DoD per team
- pas DoD continu aan (inspect & adapt)
- integreer de DoD in DevOps workflows
8. Veelgemaakte fouten
- vage criteria (“code getest”)
- geen duidelijke afspraken binnen team
- DoD verwarren met acceptance criteria
- DoD niet toepassen op alle work items
- DoD te groot en onwerkbaar maken
- DoD niet bijwerken
9. Samenvatting
De Definition of Done bepaalt wanneer werk:
- compleet is
- voldoet aan kwaliteitseisen
- gereed is voor oplevering
👉 De DoD zorgt voor duidelijke afspraken, consistente kwaliteit en voorspelbare delivery.