Veel scrum teams maken gebruik van een Definition of Ready (DoR). Een Definition of Ready wordt vaak omschreven als: De criteria waaraan een user story moet voldoen voordat de story in een sprint opgenomen kan worden.

Deze omschrijving heeft tot belangrijke misverstanden geleid, die we met dit artikel proberen de wereld uit te helpen. Het artikel bevat letterlijke passages uit het boek Requirements in Scrum.

Geschreven door Nicole de Swart, ook auteur van Handboek Requirements

Download hier de sneak preview  

Laten we beginnen met een voorbeeld van een Definition of Ready. Dan wordt het meteen duidelijk waarover we praten.

Criteria die je vaak terugziet in een DoR zijn: 

  • Het belang en de inhoud van de user story is voor iedereen duidelijk
  • De user story is maximaal x story points groot
  • We kunnen de user story onafhankelijk van andere teams en externe partijen realiseren
  • Er zijn acceptatiecriteria aan de user story toegevoegd
  • Voor belangrijke schermen is een mock-up gemaakt

Sprint ready user stories

Het ready maken van user stories gebeurt tijdens product backlog refinements. Daarin worden user stories opgesplitst en verder uitgewerkt door het scrum team (inclusief de product owner), met als doel om de user stories geschikt te maken voor opname in de sprint.

Dat wil zeggen dat ze klein en duidelijk genoeg zijn om als input voor de sprintplanning te dienen. Deze user stories worden vaak ‘ready’ of ‘sprint ready’ stories genoemd. 

Of een user story sprint ready is, bepaalt het scrum team zelf en kan derhalve voor elk team anders zijn.

Het gaat erom dat alle teamleden begrijpen wat de user story inhoudt, zodat ze zich een goed beeld kunnen vormen van de werkzaamheden die nodig zijn om de user story te implementeren. 

Veel teams maken een checklist met criteria die ze langslopen om te bepalen of een user story ready is. Die checklist staat bekend als de Definition of Ready. 

Definition of Ready als richtlijn

In de Scrum Glossary staat de volgende omschrijving van ready.

Ready: a shared understanding by the Product Owner and the Developers regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

Er staat geen “required level of description” maar “preferred level of description”. Dat is omdat de criteria bedoeld zijn als richtlijn, niet als verplichting!

Definition of Ready is daarom eigenlijk een verkeerd gekozen naam, want definition suggereert een verplichting. 

De checklist is bedoeld als werkafspraak tussen de teamleden om te voorkomen dat ze bij refinements iets over het hoofd zien.

Niet voldoen aan alle criteria op de checklist mag geen argument zijn om een user story tegen te houden. Het gaat erom of de user story klein en duidelijk genoeg is om als input voor de sprintplanning te dienen. 

Ready for sprintplanning

De laatste vier woorden in bovenstaande omschrijving van ready, “introduced at Sprint Planning”, mag je niet over het hoofd zien.

Toch wordt de Definition of Ready in de prakijk vaak ten onrechte gehanteerd als “ready for development” of “ready for completion”. 

Daarmee zeg je impliciet dat er tijdens de sprintplanning en de bouw geen requirements meer uitgewerkt hoeven te worden. Dus dat alle requirements helemaal duidelijk moeten zijn voordat de sprint start.

Daarmee creëer je feitelijk een afzonderlijke requirements- en een bouwfase, wat een van de voornaamste kenmerken van een watervalaanpak is. 

Bij een agile aanpak wil je dat analyse, ontwerp, bouw en test activiteiten elkaar gedeeltelijk overlappen. Je wilt dat het multidisciplinaire team gezamenlijk bepaalt wat de beste oplossing is en die oplossing ook samen implementeren.

Waardevolle tool (of niet)

Een Definition of Ready kan het scrum team houvast geven tijdens product backlog refinements. Het verkleint de kans dat het team tijdens de sprint in de problemen komt doordat ze een verkeerd beeld van de requirements hebben. 

Te ver doorslaan in het detailleren van de user stories voorafgaande aan de sprint maakt het scrum team inflexibel. Als al precies vastligt wat ze moeten bouwen, ontneem je het team de ruimte om onvoorziene zaken op te vangen en gebruik te maken van voortschrijdend inzicht.

De Definition of Ready is geen onderdeel van Scrum. Je kunt het, net als vele andere technieken, aanvullend op het verplichte Scrum raamwerk gebruiken. Dat hoeft echter niet. Maar als je het gebruikt, doe het dan op de agile manier.

Wat zijn jou ervaringen met de Definition of Ready? Vind je het een waardevolle tool of juist niet? We horen graag van je in een reactie hieronder.

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

2 reacties

  • Marc

    Denk dat vaak de DoR wel als Ready for Development wordt benaderd. Pseudo-agile zeg maar. Mooie verhelderende blog!

  • Marc

    Wat mij betreft is het eerste criteria verreweg het belangrijkst. Dit vereist wel goed overleg tussen de product owner, de ontwikkelaars en eventueel de gebruikers om er zeker van te zijn dat iedereen ook daadwerkelijk hetzelfde beeld heeft van het belang en de inhoud van de user story. De overige criteria die worden genoemd werken naar mijn idee te beperkend.

Geef een reactie