Wanneer is een taak voldoende uitgewerkt om deze te kunnen starten? Met de Definition of Ready heb je een krachtige checklist bij de hand die je helpt dit voor alle taken op gelijke wijze te toetsen. In dit artikel leg ik je de veelgebruikte INVEST-checklist uit en duiken we verder in de Definition of Ready en de verschillen met de Definition of Done.

Korte samenvatting

De “Definition of Ready” is een checklist die bepaalt of taken goed uitgewerkt zijn voordat ze in een Sprint worden opgenomen, essentieel voor zowel scrum als agile projecten.
Het is een set van acceptatiecriteria die bevestigt dat een user story voldoende duidelijk en goed uitgewerkt is, en helpt om latere problemen in het project te minimaliseren.
Door alle user stories te laten voldoen aan de “Definition of Ready”, wordt tijd bespaard en wordt voorkomen dat onvoldoende uitgewerkte user stories in een sprint belanden.
Het opstellen van een “Definition of Ready” gebeurt vaak aan de hand van de INVEST-criteria, wat staat voor Independent, Negotiable, Valuable, Estimable, Small en Testable.

De Definition of Ready

De Definition of Ready is een krachtige manier om ervoor te zorgen dat alle taken die op gaat nemen in je Sprint goed uitgewerkt zijn.

ik raad je daarom alsnog aan om de Definition of Ready toe te passen bij scrum en agile projecten als een extra scrum artifact.

Wat is de Definition of Ready dan?

Het is in principe een door het team vastgelegde checklist die je naloopt voordat je een user story op gaat nemen in een sprint.

Het is dus een lijst met acceptatie criteria om vast te stellen dat een story echt goed genoeg en duidelijk is uitgewerkt. Je hoeft niet op alle punten de volle 100% te scoren om de story succesvol te kunnen opleveren.

Echter, hoe beter de Definition of Ready is gevolgd des te beter je stories zijn uitgewerkt en des te minder kans op gezeik je krijgt verderop in je project.

De toegevoegde waarde van de Definition of Ready

Ok de Definition of Ready is dus een checklist om te kijken of een user story goed hebt uitgewerkt. Waarom wil je dit?

Wanneer alle user stories voldoen aan de Definition of Ready zal je het uiteindelijk tijd besparen. Zo hoef je hier niet op een later moment pas mee bezig te gaan (bijv. de sprint planning meeting).

Hoe eerder je weet hoe goed een user story is uitgewerkt, des te beter. Je wil voorkomen dat niet voldoende uitgewerkte user stories in een sprint belanden.

Zodra dat gebeurt kan je project management aan alle kanten gaan piepen en kraken of ben je overgeleverd aan de goden.

Investeer daarom aan de voorkant wat extra tijd om het de user stories goed te toetsen. Die tijd verdien je dubbel en dwars terug later in het traject.

Dat is een mooi bruggetje: hoe maak je de Definition of Ready? Met de INVEST-criteria

Hoe maak je een Definitie of Ready

Als je een user story hebt gemaakt wil je deze dus controleren aan de hand van de Definition of Ready. Een veelvoorkomende manier om de Definition of Ready in te vullen is volgens de INVEST-criteria. INVEST staat voor:

Independent
Negotiable
Valuable
Estimable
Small
Testable

Wanneer een user story niet aan één of meerdere van deze criteria voldoet, dan is het aan te raden om met het team de user story nog even te bekijken en aan te scherpen voordat deze in de Product Backlog terecht komt.

Je kan in principe andere of aanvullende zaken opnemen naast de INVEST-criteria, maar deze 6 punten geven je een goede uitgangspositie.

Hieronder deze zes criteria verder uitgelegd.

INVEST-criteria voor een user story

Independent of Onafhankelijk

Een user story moet zo onafhankelijk als mogelijk zijn van andere user stories. Waarom is dat belangrijk? Zo kan je gemakkelijk prioriteiten stellen en user stories onafhankelijk oppakken. Als er overal afhankelijkheden zijn, kan het enorm lastig worden om alles werkend en gepland te krijgen. Je kan dan verzeild raken in een web van afhankelijkheden tussen user stories waardoor je uiteindelijk niet de progressie maakt die je hoopt. Heb je enorm veel onderlinge afhankelijkheden tussen je user stories? Dan moet je je zelfs afvragen of scrum of agile wel de juiste weg is.

Negotiable of Onderhandelbaar

Een story moet duidelijk zijn, maar niet per se gebeiteld in steen. Het is een startpunt om te praten, met de stakeholders, het scrum team en de Product Owner. Je wil voldoen aan de behoefte van de klant, niet per se precies bouwen wat zij zeggen dat ze willen. Nu zullen sommige user stories meer onderhandelbaar zijn dan andere. Echter, in een goed uitgewerkte user story zie je dat er in ieder geval enige ruimte moet zijn om met elkaar de behoefte tegen het licht te houden van verschillende invalshoeken om zo tot een weloverwogen user story te komen.

Valuable of Waardevol

Tja. Als het goed is slaat elke user story ergens op in het grotere verhaal. Het klink zo simpel: een user story moet waardevol zijn. Het zal je echter verbazen hoe vaak je software of producten ziet waar er onvoldoende is nagedacht over de toegevoegde waarde van de user story. Dat is een gemiste kans en ter gelijke tijd verspilde moeite.

Estimable of Inschatbaar

De hoeveelheid effort of tijd die een user story gaat kosten moet door het scrum team in alle redelijkheid in te schatten zijn. Dat betekent dat er misschien nog extra onderzoek nodig blijkt om te bepalen wat de implicaties van de user story precies zullen zijn. Wat mij betreft is het de rol van het scrum team om ervoor te waken en ervoor te zorgen dat een taak inschatbaar is.

In veel gevallen zal je zien dat dit samenvalt met de volgende op de lijst “Small-criteria” en “negotiable” omdat je als scrum team zonder in te schatten user story geen idee hebt waar je aan begint.

Is een user story niet inschatbaar en je verzuimt deze verder uit te specificeren, dan ga je met je scrum of agile team praktisch gezien gewoon op avontuur.

Dat kan dan een groot succes worden of je kan ergens halverwege stranden.

Scrum of agile projecten zijn niet de plek om avontuurlijk te zijn wat mij betreft. Dus je wil user stories inschatbaar maken.

Dat doe je door ze kleiner te maken en ze negotiable te houden. Zo voorkom je dat een opdrachtgever of user een user story doordrukt die niet in te schatten is.

De product owner kan (of moet!) dit aangeven bij de opdrachtgever

Gelukkig kan je later in het proces slecht geschatte user stories nog bijwerken of terugsturen. Bijvoorbeeld door middel van Product Backlog refinement.

Small of Klein

Het hele idee van user stories is dat het kleine, duidelijke blokjes werk oplevert. Hoe kleiner de blokjes werk worden, hoe beter ze in te schatten zijn.

Een vuistregel die je nog wel eens ziet terugkomen is dat een user story maximaal 3-4 dagen werk mag kosten.

Is je user story nou toch behoorlijk groot? Dan zal je deze het beste kunnen opsplitsen in een aantal kleinere user stories.

Testable of testbaar

Als laatste criteria komt de testbaarheid of “testability” van een story voorbij. Uiteindelijk moet de story wanneer opgeleverd goed te testen zijn door het QA team.

Dit gaat niet alleen over software development, maar geldt ook voor andere niet-software producten.

Je moet kunnen vaststellen dat je user story werkt en voldoet aan de wensen van het team.

Hou de Definition of Ready bij met projectmanagement software

De Definition of Ready is in principe een kleine checklist dat je wil nalopen en afvinken.

Toch kunnen er hier en daar wat taken uitkomen voor het team en het is het zoveelste scrum artifact die je wil bijhouden.

Daarom raad ik je sterk aan om het niet in excelletjes of word-bestanden bij te gaan houden. Doe het in een projectmanagement tool.

ClickUp is zo’n tool, waar ik zelf veel mee werk. In ClickUp kan je gemakkelijk scrum projecten inrichten en alles op een samenhangende wijze bijhouden.

Ook de Definition of Ready kan je hier gemakkelijk tracken en in bijvoorbeeld in het template vatten van een user story.

ClickUp is gemakkelijk te gebruiken en werkt op basis van een freemium model. In veel gevallen is “free” in “freemium” maar beperkt. Bij ClickUp kan je er in principe al een heel scrum- of agile project mee managen.

Beste planning en project software van nu
Krachtige en toegankelijke tool
Slimme automation
Geen creditcard of aanbetaling nodig

Probeer gratis

Ik raad je aan het te proberen.

Mocht het je bevallen en je meer willen, dan kun je voor een paar euro per maand per teamlid je agile of scrum team een vliegende start gunnen.

Wil je meer weten over planning software? Lees dan deze blog. Wil je meer weten over ClickUp? Lees dan onze review.

De Definition of Ready en de Definition of Done

Vaak worden de Definition of Done en de Definition of Ready door elkaar gehaald. Het is ook wel wat verwarrend. Is iets dat Done is niet ook Ready?

Het concept van beide is hetzelfde. Het is een kwaliteitstoets die je wil uitvoeren voordat je iets als Done of Ready aanmerkt.

De Definition of Done is een lijst met vereisten waaraan een user story moet voldoen zodat het team deze echt als afgerond kan beschouwen.

De Definition of Done doe je dus NA de sprint. Je bekijkt het daadwerkelijke product en kijkt of deze inderdaad toereikend is t.o.v. je user story.

Mocht je hierover meer willen weten, lees dan dit artikel over de Definition of Done.

Tot slot: Definition of Ready bespaart je tijd

Al met al kan je door de INVEST-criteria toe te passen tijd besparen verderop in het traject. Soms zal het wat onnodig voelen. Toch raad ik je aan om het gewoon te (blijven) doen.

Naarmate van tijd zal je als team er een goed gevoel voor krijgen wanneer een user story duidelijk is en wanneer nog niet.

Dan heb je aan een half woord genoeg, maar toch helpt de Definition of Ready je ook dan. Zelfs het meest ervaren team laat wel eens iets erdoor glippen namelijk.

Ik ben benieuwd hoe jij tegen de Definition of Ready aankijkt en of het jou helpt. Laat het hieronder weten!