Wat is de definition of done?

In iedere organisatie wordt Scrum en Agile net iets anders gebruikt. En dat is wat ons betreft helemaal oké. Toch is het naar onze bescheiden mening goed om als product owner even stil te staan bij enkele termen die vaak door elkaar heen worden gebruikt: ‘definition of done’, ‘definition of ready’ en ‘acceptatie criteria’. In deze blog leggen wij je het verschil uit.

De definition of ready (DoR) is een vaste lijst met criteria waaraan een product backlog item (de grote to-do lijst) moet voldoen om op te kunnen nemen in de sprint backlog (het werk dat we de komende periode gaan doen). De definition of done is een vaste lijst met punten waar iedere user story aan moet voldoen om als done te worden afgestreept. De acceptatie criteria zijn voor elke specifieke user story anders en laten zien wanneer de story bruikbaar is. Wat ze allemaal gemeenschappelijk hebben: ze zorgen voor transparantie en heldere verwachtingen. En dus minder rework, minder doorlooptijd en een hogere output. Dat resulteert weer in een toffer product en dus blijere gebruikers. Het is dus goed om bij de sprint review stil te staan bij de toepasbaarheid en volledigheid van deze lijstjes.

De definition of ready is dus een checklist van drie tot tien items waar elk product backlog item aan moet voldoen voordat deze klaar is om opgenomen te worden in de sprint backlog. Het is geen officieel onderdeel van het Scrum framework, maar het maakt wel voor iedereen duidelijk wanneer het opgepakt kan worden door het team. De definition of ready wordt in de meeste gevallen bepaald door het gehele team. Met een goede DoR krijg je alleen complete en goed doordachte user stories in een sprint. Een voorbeeld van een DoR is: De acceptatie criteria zijn bekend en toegevoegd.

Zeker voor beginnende product owners is het verstandig om samen met het team de DoR te bepalen en dit lijstje te gebruiken voor het opstellen van de user stories. Hiermee krijg je snel de voorwaarden helder waar een product backlog item aan moet voldoen. De user stories worden hier beter van. Dit is ook prettig voor het team en onze ervaring is dat een refinement sessie efficiënter verloopt. Wil je hier meer over weten? Lees dan hoofdstuk 25 van het product owner boek. Wil je meer begeleiding in het opstellen van een goede user story? Kijk dan eens naar onze product owner basistraining, een eendaagse praktische training geheel toegespitst op jouw situatie.

De definition of ready definieert de criteria waaraan een specifieke user story moet voldoen voordat hij in aanmerking komt voor opname in een sprint. Voorbeelden van de definition of ready zijn:

Dit lijstje komen we vaker in dit format tegen. Wij raden dan ook aan met dit lijstje te beginnen en steeds bij elke user story na te gaan of het er is. Mocht je als team na verloop van tijd een extra punt voor de op de lijst tegenkomen, dan kan die worden toegevoegd.

Eentje die onze product owners vaak willen toevoegen is dat we zeker willen weten dat de business ook doordrongen is dat deze feature er aan komt en er dus actie moet worden ondernomen. Voorbeelden daarvan zijn:

De definition of done (DoD) is een checklist waar ieder sprint backlog item aan moet voldoen om klaar te zijn voor ingebruikname. De definition of done wordt bepaald door het ontwikkelteam. Dit is vaak een checklist van drie tot tien items. Een sprint backlog item is klaar voor oplevering als het aan de definition of done en de acceptatie criteria voldoet. De product owner is verantwoordelijk voor de acceptatie criteria.

Een goede definition of done is belangrijk, omdat het de richtlijn is waar door iedereen telkens aan voldaan dient te worden. Hiermee ontstaat er consensus over de beoogde kwaliteit en ontstaat er een duidelijk beeld wanneer een item bij een review getoond kan worden. Het behoeft hopelijk geen betoog dat in beide gevallen harmonie en samenspraak beter werkt dan afdwingen.

De definition of done wordt dus niet alleen door de product owner opgesteld, maar door het hele team en misschien zelfs wel met de hele organisatie samen. Het zijn criteria die voor het hele product gelijk zijn, ongeacht welk team eraan werkt. Als een item niet aan de DoD voldoet dan wordt dit als niet-gereed beschouwd en gaat het terug naar de product backlog.

Als een team langer samenwerkt aan het product, dan ontstaat er voortschrijdend inzicht. Het is goed om de definition of done elke 2-3 sprints onder de aandacht te brengen tijdens de review.

1. Laat iedereen deze blog lezen of laat een ervaren persoon het de groep uitleggen.
2. Laat iedereen 5-10 minuten naar de backlog kijken en vragen stellen aan de product owner over specifieke stories. Het doel is om inzicht te krijgen in wat er voor werk ligt. Het is niet de bedoeling om alles tot in detail uit te pluizen, dus time cap op 10 minuten is aan te bevelen.
3. Iedereen schrijft voor zichzelf drie post-it’s met belangrijkste punten waaraan al het werk moet voldoen. Dit doet iedereen vanuit zijn eigen overtuiging/expertise. Er is geen goed of fout.
4. Iedereen krijgt 1 minuut om zijn post-it’s toe te lichten. Hang ze vervolgens allemaal op 1 whiteboard/raam/deur. Meteen ontdubbelen.
5. Door middel van dot voting met stickers of stippen van een stift kun je bepalen hoe de groep hier naar kijkt. Aantal stickers = teamleden gedeeld door 2. Je mag op jezelf stemmen. Op je baas stemmen of die hele leuke collega is een minder goed idee (tenzij het een goed idee is natuurlijk). Als er al een sticker hangt en je vindt het een goed idee; vooral doen. Het resulteert namelijk in een heat map.
6. Probeer een top 3-5 te vinden voor de eerste versie. Let op in het uiteindelijke selecteren heeft het ontwikkelteam het beslisrecht.
7. Spreek met elkaar af om periodiek (elke of om de sprint in de review/retro) te reviewen.

Acceptatiecriteria zijn punten waar een specifiek product backlog item aan moet voldoen. Waar de DoR en DoD gelden voor álle items, gelden acceptatiecriteria enkel voor een specifiek item en kunnen ze per item flink verschillen. In de Scrum Guide wordt niet gesproken over acceptatiecriteria, maar het is een zeer breed gedragen onderdeel van user stories. Je gebruikt het als product owner om extra input mee te geven over waar een item aan moet voldoen voordat het klaar is. 

Acceptatie criteria gelden dus voor één specifieke user story. Het geeft antwoord op de vraag wat er op moet worden geleverd om de nieuwe feature daadwerkelijk te kunnen gaan gebruiken. De acceptatiecriteria voeg je aan de product backlog items toe om zeer specifieke zaken voor dat item uit te lichten; de zaken die écht waarde toevoegen. Het helpt om de behoefte van de gebruiker nog duidelijker over te dragen. Daarnaast weet het ontwikkelteam dat de functionaliteit die wordt opgeleverd alleen door jou wordt geaccepteerd als het aan alle criteria wordt voldaan.

Hieronder een voorbeeld van de acceptatie criteria bij een inlog functionaliteit op een website:

Het bepalen van acceptatie criteria is geen exacte wetenschap, maar gelukkig ook niet complex. Aan de hand van het volgende stappenplan kan je bij de eerstvolgende sprint al gaan werken met acceptatie criteria.

1. Bepaal wie de acceptatietest van deze user story gaat doen. Is het een developer, een tester, de product owner, een super user of nog iemand anders? Of is het een gezamenlijke inspanning? De mensen die testen zouden wat ons betreft betrokken moeten worden bij het opstellen van de acceptatie criteria
2. Laat de product owner – voor zover niet duidelijk – uitleggen wat deze story oplost voor de gebruiker. Doe waar nodig Q&A.
3. Stel al pratend en luisterend een aantal punten op die belangrijk zijn voor de gebruiker. In ons voorbeeld hierboven was het email, facebook, foutmelding, landen.
4. Stel per punt één of meerdere acceptatie criteria vast aan de hand van bovenstaande herkenningspunten. (meetbaar, realistisch, losstaand)
5. Doen. zeker in het begin is het lastig en je kan met een onzeker gevoel rond blijven lopen omdat je – ondanks goede voorbereiding – soms de uitkomst niet perfect kan voorstellen. Staar je niet blind op een perfecte lijst tijdens de eerste sprints.
6. Evalueren. Bij een sprint review is het goed om de acceptatie criteria te overlopen. De ervaring van onze product owners is dat naarmate het team en het product groeit, de acceptatie criteria steeds beter worden.

In het begin kan dit als product owner lastig zijn. Zowel bij de definition of done als bij acceptatie criteria geldt dat je met het team aan de slag moet gaan en het in de praktijk moet ondervinden. En als je tijdens de reviews aandacht besteed aan de kwaliteit en inzetbaarheid van zowel de definition of done als de acceptatie criteria, dat je kwaliteit dan altijd zal gaan stijgen. Met blijere klanten en stakeholders tot gevolg.

Wij helpen jou graag verder ontwikkelen als product owner, bekijk hier onze trainingen voor product owners. Ben je op zoek naar een product owner die stil kan staan bij jouw definition of done? In ons netwerk van +7.000 product owners gaan wij graag voor je op zoek. Krijg dezelfde dag nog reactie en vrijblijvend advies.