Definition of Ready (DoR)

De meeste Agile scrum teams zijn bekend met de Definition of Done (DoD).

Het Agile scrum team hanteert de “Defintion of Done” (DoD) om een user story af te krijgen volgens een aantal generieke afspraken. Eigenlijk, en dat is mijn persoonlijke mening, is een user story pas echt af, als deze niet alleen in productie en beheer is genomen, maar pas wanneer de gebruikers tevreden zijn over de nieuwe functionaliteit en wanneer echt blijkt dat deze nieuwe functionaliteit echt waarde toevoegt.

ready

Definition of Ready (DoR)

Wanneer ik Agile scrum teams als Agile coach begeleid kom ik vaak tot de conclusie dat men wel aandacht heeft geschonken aan de “Defintion of Done” (DoD) maar nog niet aan de “Definiton of Ready” (DoR).

Omdat ik beide belangrijk vind, en omdat het efficiënter is gebleken om ook een DoR te hebben ben ik er voorstander van om de DoR toe te passen. In veel gevallen is er ook geen refinement (voorheen grooming) van de product backlog, en is het ook meestal zo dat de product owner niet vraagt aan het team of viceversa of userstories compleet voldoende zijn en/of eventueel te groot.

Tijdens de sprint planning sessie stuit het team vaak op onvolledigheid van de user stories en mist er nog teveel informatie om echt goed te kunnen inschatten hoe complex een userstory precies is. Wanneer deze informatie nog niet op voorhand aanwezig is men tijdens de sprint planning niet in staat commitment te geven voor de userstory.

In de praktijk ziet men dit vaak door de vingers, in de hoop dat de informatie in de sprint alsnog boven water komt drijven, en wordt er toch commitment door het team afgegeven.
Is dit commitment dan gebaseerd om de product owner tevreden te stellen?
Het is namelijk zo dat deze ontbrekende informatie niet gedurende de sprint zal worden opgeleverd door de product owner. De product owner is dan namelijk al weer gefocused op de volgende 2-4 sprints. Tevens zullen er door het ontbreken van informatie of randvoorwaarden allerlei belemmeringen (impedements) gaan voorkomen om de userstory op Done te krijgen.  Uiteindelijk zal de user story niet compleet worden opgeleverd, of de kwaliteit en functionaliteit is net niet dat wat de gebruikers hadden verwacht. In het ergste geval wordt er niets opgeleverd gedurende de sprint.

Door informatie rondom de user story vooraf vollediger te maken, zal bij de inname van de user story tijdens de sprint planning alles duidelijk moeten zijn waardoor met name ook de sprint planning efficiënter kan verlopen. Natuurlijk als er tussen de refinement sessie en de sprint planning in nog verandering van inzicht is gekomen of nieuwe informatie beschikbaar komt, dan dient deze wel helder gemaakt te worden.

Met name bij beginnende scrum teams is het verstandig om een separate refinement sessie te houden waarbij de user story’s voor de komende 2-4 sprints worden getoetst op volledigheid. In een later stadium wanneer de teams hechter zijn en volwassener worden is het normaliter de gewoonte om refinement als een proces mee te nemen gedurende de sprint. Men claimt dan een deel van de sprint capaciteit om de product backlog samen met de product owner smarter en completer te maken. Meestal is dat tussen de 5 tot 10% van de tijd. Dus in 2 weken tijd ongeveer 3 uur.

De “Definition of Ready” (DoR) kan natuurlijk per project verschillen. Wanneer het team samen met de product owner consensus hebben bereikt over de “Definition of Ready” (DoR) kan er worden begonnen met het ready maken van de user stories op de Product backlog. In veel gevallen heeft de product owner nog wat werk te doen om de story compleet te maken. Hij of zij zal in de meeste gevallen dan nog informatie boven water moeten krijgen vanuit de business. (stakeholders en/of gebruikers).

Hieronder volgt een lijstje van “Definition of Ready” (DoR) items als voorbeeld:

  • Is de user story goed omschreven en helder zodat het team begrijpt wat er bedoeld wordt.
  • Is er aan de user story een document of link gekoppeld naar andere stories?, zo ja, dient deze ook worden meegenomen.
  • Zijn er specifieke acceptatie criteria die voor de user story gelden t.o.v. de generieke acceptatie criteria.
  • Is er ook afhankelijkheid met andere functionaliteit.
  • Is door de stakeholders ook al een inschatting gemaakt op complexiteit (bijvoorbeeld t-shirt sizes).
  • Is input van gebruikers gewenst?
  • Criteria met betrekking tot performance?
  • Is er een user (of super-user) nodig om tijdens het bouwen van de nieuwe functionaliteit om verduidelijking aan te brengen.
  • Het scrumteam weet wat zij moeten demonstreren in de demo/review met betrekking tot de userstory.
  • Is er specifieke documentatie nodig?

Een “Definition of Ready” (DoR) kan pas worden afgegeven als de user story dus echt ready is om in een sprint opgenomen te kunnen worden. Het hoeft natuurlijk niet altijd zo te zijn dat er voor de volle 100% aan alle criteria moet worden voldaan. Als team spreek je ook af, of bepaalde informatie later kan komen. Echter dien je er wel zeker van te zijn dat je die informatie dan krijgt en dat je dus commitment kunt afgeven op een user story.

Naast de “Definition of Ready” (DoR) voor een user story is er ook sprake van het ready maken van de product backlog. Met name de items die gewenst zijn voor de volgende sprint, dienen op het netvlies van de product owner helder te zijn.

Een aantal punten waar aandacht aan kan worden besteed zijn de volgende.

  • De product backlog is geprioriteerd.
  • De product backlog is volledig en bevat al het werk waar het team commitment op geeft.
  • De beschikbaarheid van team members is bekend. (x uur per dag/week).
  • User stories beoogd voor de komende 2 sprints zijn getoetst en hebben de status Ready (definition of ready voor een userstory).