Definition of Ready

Voor betere user stories

Zo af en toe komt de vraag weer langs: wat hebben we nu als team nodig om een goede inschatting te kunnen maken van het werk wat we moeten doen. Naast het feit dat de story is opgebouwd volgens het stramien:

Als een gebruiker wil ik functionaliteit zodat ik daar wat aan heb.

Maar ja, weet je dan als ontwikkelaar precies wat je moet doen en waarom je dat doet? Ik niet. En daarom ben ik fan van het opstellen van een Definition of Ready (DoR).

Wat is een Definition of Ready?

Een DoR beschrijft wat er in een user story moet staan zodat er een goede inschatting van het werk gemaakt kan worden. Net als de Definition of Done is dit een lijst van acceptatie criteria. Alleen gelden deze niet voor de increment, maar voor de user story zelf.

De theorie is hier een beetje anders over, die zegt dat een user story ready is als het team de user story kan opnemen in een sprint. Dat betekent dat het werk ook ingeschat moet zijn aan de hand van bijvoorbeeld story points. In de praktijk heb ik vooral gezien dat een user story niet wordt opgepakt voordat deze is geschat. Iets dat al zo voor in het hoofd zit hoeven we niet nog eens in een checklist op te nemen.

Wat kan je dan in de DoR opnemen?

Zelf heb ik goede ervaringen met de volgende DoR:

• De functionaliteit is samengevat in de zin: “Als […] wil ik […] zodat ik […]”
  
  Dit geeft in het kort weer wat je voor wie doet en wat daarvan de waarde is. Bijvoorbeeld: “Als systeembeheerder wil ik een overzicht van gebruikers kunnen zien zodat ik weet wie toegang hebben tot mijn applicatie.”
  
• Er is een beschrijving opgenomen van de huidige situatie.
  
  Leg uit wat de huidige situatie is. Bijvoorbeeld: “Als systeembeheerder beheer ik mijn applicatie. Ik ben als beheerder niet de enige gebruiker van de applicatie. Zo zijn er eindgebruikers en key-users. Elke groep gebruikers heeft zijn eigen rechtenprofiel.”
  
• Het probleem met de huidige situatie is uitgelegd.
  
  Door aan te geven wat het probleem is waar je tegen aan loopt krijgt het scrum team meer context om zo een betere oplossing te voorzien. Bijvoorbeeld:”Het is voor mij niet mogelijk om te zien welke gebruiker gekoppeld is aan welke rol. Dit is lastig als de gebruiker mij belt met een vraag over mijn applicatie.”
  
• Er zijn acceptatiecriteria vastgelegd waaraan de oplossing moet voldoen.
  
  Door acceptatiecriteria op te stellen kan het scrum team beter toetsen of de uiteindelijke oplossing voldoet.
  
• Er is een voorstel gedaan voor de technische implementatie.
  
  Het team schrijft een voorstel voor een technische oplossing. Deze wordt in de refinement met het team afgestemd en bijgeschaafd. Door dit te beschrijven is het voor iedereen duidelijk wat er verwacht wordt. Als de user story een tijdje later in een sprint wordt opgenomen, dan hoeft het scrum team niet meer na te denken over wat nou ook alweer precies de bedoeling is.
  
• De story is gerefined door het scrum team.
  
  Er is overleg geweest met het scrum team en eventuele stakeholders om de inhoud van de user story af te stemmen. Zo is iedereen op de hoogte van dezelfde informatie.

Mijn ervaring is dat met de bovenstaande DoR redelijk complete user stories kunnen worden opgesteld voor het scrum team.

Ready? Go!

Ik hoop dat je uit het bovenstaande wat ideeën hebt kunnen halen. Ook beginnen met een Definition of Ready? Stel het voor bij je team.

Werk je al een poosje met een Definition of Ready en heb je nog goede suggesties? Reageer dan hieronder op deze blog.

_{Header photo by Tero Vesalainen from Freerange Stock}