π Definition of Ready (DoR)
π Introductie
Binnen softwareontwikkeling is het essentieel om te bepalen wanneer werk voldoende is voorbereid om door het development team te worden opgepakt.
Zonder duidelijke afspraken ontstaan:
- onduidelijke requirements
- incomplete user stories
- verborgen afhankelijkheden
- vertraging en rework
π De Definition of Ready (DoR) biedt een gezamenlijke set criteria waarmee wordt bepaald of een work item klaar is om in ontwikkeling te worden genomen.
π Alleen werk dat voldoet aan de DoR wordt ingepland in een sprint of iteratie.
Wat is Definition of Ready?
De Definition of Ready is een set van minimale criteria waaraan een work item moet voldoen voordat het door development kan worden opgepakt.
π Een work item is βReadyβ wanneer:
- het voldoende duidelijk is
- het uitvoerbaar is zonder grote aannames
- het team het werk kan inschatten en plannen
π Work items die niet voldoen aan de DoR worden teruggezet naar refinement.
Doel van Definition of Ready
De DoR zorgt voor:
- duidelijke en volledige requirements
- minder onzekerheid tijdens development
- betere sprint- of iteratieplanning
- minder rework en aannames
- hogere voorspelbaarheid in delivery
π Zonder DoR start development vaak op basis van interpretatie in plaats van informatie.
Relatie met andere artefacten
πΉ DoR vs Acceptance Criteria
- DoR β bepaalt of werk klaar is om te starten
- Acceptance Criteria β bepalen wanneer werk correct is afgerond
πΉ DoR vs Definition of Done
- DoR β start van de lifecycle
- DoD β einde van de lifecycle
π Samen vormen ze de kwaliteitsgrenzen van delivery.
Typische inhoud van een DoR
Een DoR bevat minimale, toetsbare criteria.
πΉ Requirements
- work item is duidelijk beschreven
- businessdoel is bekend
- scope is afgebakend
πΉ Acceptance Criteria
- acceptatiecriteria zijn aanwezig
- criteria zijn testbaar
- er zijn geen open functionele vragen
πΉ Analyse (lichtgewicht)
- afhankelijkheden zijn globaal bekend
- impact op bestaande functionaliteit is in beeld
- belangrijke aannames zijn vastgelegd
π Voor complexe items kunnen aanvullende artefacts aanwezig zijn (bijv. design notes of ADRβs), maar alleen indien nodig.
πΉ Planning
- work item is geschat of te schatten
- prioriteit is bepaald
- team begrijpt de intentie van het werk
π DoR is bewust lichtgewicht: het doel is starten zonder blokkades, niet volledige uitwerking.
Gebruik binnen ALM
π Plan & Track
- refinement van backlog items
- voorbereiding van user stories
- toetsing tijdens planning
π» Develop
- voorkomt start met incomplete of onduidelijke work items
- vermindert rework en interpretatieverschillen
π DoR vormt de brug tussen analyse en uitvoering.
Lifecycle en beheer
πΉ Gezamenlijk opgesteld
De DoR wordt afgestemd tussen:
- Product Owner
- Business / stakeholders
- Consultants
- Developers
- Architect (indien nodig)
πΉ Evolueert over tijd
- wordt aangescherpt op basis van teamervaring
- groeit mee met volwassenheid van het deliveryproces
π De DoR is een levend werkafspraakdocument.
πΉ Toepassing in ceremonies
- Refinement β toetsen van readiness
- Planning β alleen βreadyβ items worden opgenomen
Best practices
- houd criteria concreet en toetsbaar
- voorkom over-engineering van DoR
- gebruik DoR actief in refinement
- maak het een teamafspraak, geen PO-document
- combineer altijd met goede acceptance criteria
Veelgemaakte fouten
- starten met incomplete user stories
- ontbreken van acceptance criteria
- te zware of bureaucratische DoR
- afhankelijkheden pas tijdens development ontdekken
- DoR niet actief gebruiken in refinement