Introductie
Het is essentieel om eenduidig te bepalen wanneer werk klaar is om opgepakt te worden door het development team. Zonder duidelijke afspraken ontstaan problemen in planning, uitvoering en kwaliteit.
- onduidelijke requirements en interpretatieverschillen
- incomplete user stories zonder context
- onverwachte afhankelijkheden tijdens uitvoering
- vertragingen en rework door ontbrekende informatie
👉 Definition of Ready (DoR) helpt teams om te bepalen wanneer werk voldoende voorbereid is om efficiënt en voorspelbaar uitgevoerd te worden.
1. Wat is Definition of Ready
De Definition of Ready is een set criteria die bepaalt of een backlog item klaar is om opgepakt te worden. Hiermee wordt voorkomen dat teams starten met werk dat nog onduidelijk of incompleet is.
- duidelijk en begrijpelijk voor het team
- voldoende context aanwezig
- uitvoerbaar binnen een sprint of iteratie
👉 Alleen items die voldoen aan de DoR worden ingepland.
2. Doel
De DoR draagt bij aan een stabiel en voorspelbaar delivery proces door onzekerheden en risico’s vooraf te reduceren.
- duidelijke requirements
- betrouwbare planning
- minder rework
- hogere voorspelbaarheid
3. Relaties
DoR vs Acceptance Criteria
Hoewel DoR en Acceptance Criteria vaak samen voorkomen, hebben ze een verschillend doel binnen het proces.
-
DoR (Definition of Ready) – bepaalt of het werk klaar is om te starten
-
Acceptance Criteria – beschrijven wanneer het werk functioneel correct is opgeleverd
DoR vs DoD
De Definition of Ready (DoR) en de Definition of Done (DoD) vormen samen de kwaliteitskaders binnen een iteratie of sprint.
-
DoR (Definition of Ready) – bepaalt wanneer werk voldoende voorbereid is om opgepakt te worden
-
DoD (Definition of Done) – bepaalt wanneer werk volledig afgerond en van voldoende kwaliteit is opgeleverd
De Definition of Done bevat criteria zoals:
- functionaliteit is ontwikkeld en voldoet aan de requirements
- testen zijn uitgevoerd en succesvol afgerond
- code is gereviewd en geïntegreerd
- documentatie is bijgewerkt
- oplossing is gereed voor deployment
👉 Waar de DoR de kwaliteit van voorbereiding borgt, borgt de DoD de kwaliteit van de oplevering.
DoR → Development → DoD
👉 Samen zorgen deze kaders voor een voorspelbaar en beheersbaar delivery proces.
4. Inhoud van DoR
Requirements
- duidelijk beschreven
- business waarde bekend
- scope afgebakend
Acceptance Criteria
- aanwezig en testbaar
- eenduidig geformuleerd
Analyse & Design
- oplossing op hoofdlijnen uitgewerkt
- impact inzichtelijk
- afhankelijkheden bekend
Techniek
- data en structuur gedefinieerd
- integraties bekend
- platform randvoorwaarden helder
Planning
- ingeschat door team
- prioriteit bepaald
- team begrijpt het werk
5. Gebruik binnen ALM
Plan & Track
- toegepast tijdens refinement
- helpt backlog structureren
Develop
- vermindert onzekerheid
- voorkomt onderbrekingen
6. Stakeholders
- Product Owner – bewaakt waarde en prioriteit
- Consultants – analyse en uitwerking
- Developers – beoordelen haalbaarheid
- Architect – bewaakt samenhang
7. Best practices
- maak DoR concreet en toetsbaar
- gebruik DoR actief in het team
- pas DoR toe tijdens refinement en planning
- zorg voor gezamenlijke alignment
8. Veelgemaakte fouten
- items plannen zonder DoR
- vage requirements accepteren
- afhankelijkheden te laat ontdekken
- DoR alleen documenteren maar niet gebruiken
📊 Conceptueel model
Definition of Ready
↓
Development
↓
Definition of Done
👉 Dit model maakt de overgang van voorbereiding naar uitvoering en oplevering inzichtelijk.
Samenvatting
Definition of Ready bepaalt wanneer werk voldoende voorbereid is om te starten. Door duidelijke criteria te hanteren ontstaat een efficiënter, voorspelbaarder en beter beheersbaar delivery proces.