Onze huidige DoR

Hoe ziet onze Definition of Ready er vandaag uit?

We zeggen dat een story gereed is als er acceptatiecriteria zijn, maar ik denk niet dat iedereen het eens is over wat 'goede' acceptatiecriteria zijn.
Onze DoR bevat: user story geschreven, acceptatiecriteria gedefinieerd, story gepointed en afhankelijkheden in kaart gebracht.
Eerlijk gezegd weet ik niet zeker of we wel een formele DoR hebben. We pakken gewoon wat bovenaan de backlog staat.
Wanneer het werkt

Wat gaat er goed als stories aan onze Definition of Ready voldoen?

Als stories goed op maat zijn en duidelijke acceptatiecriteria hebben, gaat de sprintplanning veel sneller. Dan zijn we binnen een uur klaar.
Ik merk dat we veel minder blokkades halverwege de sprint hebben als afhankelijkheden al tijdens de refinement benoemd worden.
Het team durft zich met meer vertrouwen aan stories te committeren als we allemaal vóór de sprint vragen hebben kunnen stellen.
Wanneer het misgaat

Welke problemen ontstaan er als stories niet echt gereed zijn?

Vorige sprint hebben we een story zonder acceptatiecriteria opgepakt en dat liep uit op drie dagen heen-en-weer met de PO.
Stories zonder duidelijke scope worden door verschillende developers op verschillende manieren 'af' gemaakt, en dan vindt QA inconsistenties.
We ontdekken steeds halverwege de sprint afhankelijkheden die ons dagenlang blokkeren. Dat zou in de refinement boven water moeten komen.
Onze DoR verbeteren

Wat moeten we veranderen om onze Definition of Ready te versterken?

We moeten een checklist aan onze Jira-tickettemplate toevoegen, zodat er niets wordt overgeslagen voordat een story als gereed wordt gemarkeerd.
Ik zou graag afspreken dat geen enkele story een sprint in gaat zonder minstens één refinementsessie waarbij het hele team aanwezig was.
We hebben een duidelijke regel nodig: als een story 48 uur voor de planning geen acceptatiecriteria heeft, wordt hij niet ingepland.

Wat is een Definition of Ready-retrospective?

Een sprint verloopt beter als het werk al gereed was voordat de planning begon. Een Definition of Ready (DoR) is de lijst met instapcriteria waaraan een backlogitem moet voldoen voordat je team het in een sprint opneemt, zoals acceptatiecriteria, een schatting en bekende afhankelijkheden. De Definition of Ready-retrospective kijkt of die lijst doet wat hij moet doen. Het bord heeft vier kolommen. In Onze huidige DoR leg je vast wat de criteria vandaag echt zijn, en dat blijkt vaak per persoon te verschillen. Wanneer het werkt verzamelt voorbeelden van gerede stories die soepel verliepen. Wanneer het misgaat gaat over wat er gebeurde toen werk dat nog niet gereed was in een sprint belandde. In Onze DoR verbeteren spreek je wijzigingen af. Gebruik deze retrospective als de planning steeds uitloopt, stories halverwege de sprint blijven hangen of niemand al maanden naar jullie DoR heeft gekeken. Hij werkt voor zowel Scrum- als Kanban-teams. In TeamRetro kunnen mensen anoniem ideeën toevoegen, zodat problemen met refinement ook boven tafel komen als ze lastig aan te kaarten zijn.

Format van de Definition of Ready-retrospective

Onze huidige DoR

Hoe ziet onze Definition of Ready er vandaag uit?

Vraag iedereen om op te schrijven wat volgens hen de huidige criteria zijn. Veel teams hebben een informele of ongeschreven DoR, en de verschillen tussen de antwoorden laten zien waar je moet beginnen.

Wanneer het werkt

Wat gaat er goed als stories aan onze Definition of Ready voldoen?

Zoek naar concrete sprints of stories waarbij gereed zijn het verschil maakte, zoals een korte planningssessie of een story die af kwam zonder dat je iemand achterna hoefde te zitten. Zulke voorbeelden laten het team zien waarom het de moeite waard is om de DoR bij te houden.

Wanneer het misgaat

Welke problemen ontstaan er als stories niet echt gereed zijn?

Deze kolom zegt meestal het meest. Vraag naar concrete stories die een sprint in gingen zonder aan de DoR te voldoen en wat er daarna gebeurde. Let op patronen: komen dezelfde gaten steeds terug, of raken ze steeds hetzelfde soort stories?

Onze DoR verbeteren

Wat moeten we veranderen om onze Definition of Ready te versterken?

Spreek concrete wijzigingen af, zoals criteria toevoegen of schrappen, de refinement anders inrichten of je tooling aanpassen. Probeer met 1–3 wijzigingen af te sluiten die je de volgende sprint uitprobeert.

Wanneer dient u deze retrospective te gebruiken?

  • Je team loopt steeds tegen blokkades halverwege de sprint aan, krijgt te maken met scope creep of heeft stories die niet binnen de sprint af kunnen, wat vaak betekent dat het werk niet gereed was toen het werd ingepland.
  • De sprintplanning loopt uit of voelt chaotisch, omdat de backlog niet was gerefined voordat het team zich committeert.
  • Je haalt nieuwe teamleden aan boord en wilt vastleggen wat 'gereed' voor jullie team betekent.
  • Je team heeft een Definition of Ready, maar heeft die al een tijd niet bekeken en hij past misschien niet meer bij hoe jullie nu werken.
  • Na een zware sprint waarin onduidelijke requirements of ontbrekende informatie voor vertraging of dubbel werk zorgden.

Voorstellen voor ijsbrekers

  • Als je backlog een keuken was, zou het dan een goed gevulde, opgeruimde voorraadkast zijn of een chaotische koelkast vol mysterieuze restjes, en waarom?
  • Wat is iets dat je aan het begin van een taak had willen weten, maar dat je altijd pas halverwege lijkt te ontdekken?

Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →

Ideeën en tips voor uw retrospectievevergadering

  • Deel jullie huidige DoR vóór de sessie, zodat mensen met echte voorbeelden komen.
  • Praat over gaten in het proces, niet over individuele fouten, zodat mensen zonder schuldvraag kunnen vertellen wat er misging.
  • Zet een timebox op elke kolom. Gesprekken over de DoR veranderen makkelijk in het refinen van losse stories, dus houd de retro bij de criteria zelf.
  • Spreek per sessie 1–3 wijzigingen af. Een DoR die alles probeert af te dekken, wordt te lang om te volgen.
  • Betrek het hele team, niet alleen de Scrum Master of Product Owner. Developers, QA en designers merken elk op een andere manier dat stories niet gereed zijn.
  • Kijk in de volgende retrospective of de wijzigingen de planning en oplevering makkelijker hebben gemaakt.

Veelgestelde vragen

Wat is een Definition of Ready-retrospective?
Het is een retrospective waarin je de instapcriteria van je team voor backlogitems onder de loep neemt. Het bord behandelt jullie huidige DoR, wat er werkt als stories eraan voldoen, wat er misgaat als ze dat niet doen en wat je wilt veranderen.
Wat is het verschil tussen de Definition of Ready en de Definition of Done?
De Definition of Ready legt de instapcriteria vast waaraan een backlogitem moet voldoen voordat het een sprint in gaat. De Definition of Done legt de uitstapcriteria vast voor wanneer werk af is. Deze retrospective gaat over de eerste.
Hoe vaak moet een team een Definition of Ready-retrospective houden?
Houd hem na een zware sprint met onduidelijke requirements, wanneer er nieuwe mensen bij komen, of om de paar maanden om te checken of jullie DoR nog past bij hoe het team werkt.
Hoort de Definition of Ready bij Scrum?
Nee. De Scrum Guide definieert wel een Definition of Done, maar geen Definition of Ready. Veel Scrum-teams voegen die zelf toe. Houd hem licht, zodat hij geen poort wordt die nuttig werk tegenhoudt.
Hoe lang duurt een Definition of Ready-retrospective?
Voor de meeste teams ongeveer 45 tot 60 minuten. Houd het gesprek bij de criteria zelf, anders verandert het in een refinementsessie.
Bent u klaar om deze retrospective te houden?Probeer deze retrospective live eens