Definitie van Done: voorbeeld, checklist en workshop in Scrum

Laatst bereidde ik samen met een collega een workshop voor. Over de inhoud waren we het snel eens, het enige wat nog ontbrak was een geschikte PowerPoint presentatie. Om zo efficiënt mogelijk aan de presentatie te kunnen werken, verdeelden we deze thematisch. Toen we vervolgens gingen zitten om de voltooide opzet te bespreken, werd een groot probleem duidelijk: we hadden heel verschillende ideeën over wat nu eigenlijk een “voltooide opzet” is. 

Dit probleem kan zich ook voordoen in agile Scrum-teams. Na twee weken bereikt het team het einde van de sprint, maar er is onenigheid over de vraag of het productdeel al klaar is en van “in uitvoering” naar “klaar” kan worden verplaatst. Deze onenigheid leidt tot discussies, die op hun beurt het klimaat in het team negatief beïnvloeden. Om deze discussies te voorkomen en effectief teamwerk te beschermen, is er in de Scrum-wereld een artefact dat “Definition of Done” (DoD) heet. 

Wat is de Definitie van Done in Scrum?

De Definitie van Done is de gezamenlijke kwaliteitsafspraak van een Scrum-team. Ze beschrijft welke voorwaarden vervuld moeten zijn, zodat een increment als af en bruikbaar geldt. Het is geen persoonlijke takenlijst en geen extra acceptatie door één enkele rol, maar een transparante standaard voor het hele team.

Letterlijk betekent Definition of Done “definitie van voltooid”. Dit betekent dat het team het eens is over wat er moet gebeuren om een functie als af te kunnen beschouwen. Praktisch gezien kan de Definition of Done worden voorgesteld als een soort checklist die tijdens de sprint en vooral aan het eind wordt gebruikt om te controleren of aan bepaalde voltooiingscriteria is voldaan. Voor software ontwikkelteams kunnen deze criteria bijvoorbeeld het volgende zijn: 

Definitie van Done voorbeeld: checklist voor Scrum-teams

Een praktisch bruikbare Definitie van Done kan voor een softwareproduct bijvoorbeeld de volgende criteria bevatten:

• Aan de acceptatiecriteria en vakinhoudelijke eisen is voldaan.
• Er is documentatie opgesteld.
• De code is volledig geïmplementeerd en becommentarieerd.
• Er is een code review uitgevoerd.
• Geautomatiseerde tests lopen succesvol; relevante fouten en veiligheidsrisico’s zijn behandeld.
• De wijziging is geïntegreerd en kan in een productieachtige omgeving worden gecontroleerd.
• Monitoring, logging en indien nodig release notes zijn meegenomen.
• Het increment is bruikbaar en voldoet aan de kwaliteitsnorm van het product.
• …

Deze lijst is een voorbeeld, geen universeel sjabloon. Een goede DoD beschermt kwaliteit, blijft voor het team in elke sprint toepasbaar en wordt aangepast wanneer product, risico’s of technische randvoorwaarden veranderen.

Definitie van Done is niet hetzelfde als producteffect

Een Definitie van Done beantwoordt een belangrijke vraag: voldoet het increment aan de afgesproken kwaliteitsnorm en is het bruikbaar? Ze beantwoordt echter niet automatisch of de wijziging in de markt of bij de klant het gewenste effect heeft bereikt.

Voor de praktijk helpt daarom een onderscheid tussen drie niveaus:

• Done: Het increment voldoet aan de Definitie van Done en kan worden gebruikt.
• Done-Done: De wijziging is geïntegreerd, uitgerold en in gebruik observeerbaar.
• Producteffect: Reële klantfeedback laat zien of de wijziging een relevant probleem oplost en de productwaarde verhoogt.

John Cutler beschrijft software daarom als een continu verder ontwikkeld servicesysteem: features zijn geen definitieve gebouwen, maar tijdelijke middelen om klantwaarde te creëren. Lees zijn perspectief in The Work Is Never Done.

Gil Zilberfeld maakt bovendien onderscheid tussen verschillende betekenissen van „Done” – bijvoorbeeld wanneer ontwikkeling, tests, oplevering of klantfeedback telkens een ander voltooiingsniveau markeren. Zijn indeling vind je in The Definition of Done, Done-Done and Really Done.

Belangrijk: „Producteffect” moet niet eenvoudig als extra DoD-criterium worden geformuleerd. Een Scrum-team moet een bruikbaar increment opleveren; of het het gewenste effect heeft, wordt daarna zichtbaar via de Sprint Review, gebruik en verdere leercycli. Juist dit onderscheid beschermt de Definitie van Done ervoor om een onhaalbare verzamelchecklist te worden.

Hoe de Definitie van Done samenwerkt met andere effectieve Scrum-praktijken laten we zien in ons artikel Scrum Best Practices 2026.

Waarom is een definitie van Gedaan belangrijk?

Dat het stellen van doelen enorm belangrijk is voor prestaties is geen nieuw inzicht. Het stellen van doelen is een veel onderzocht onderwerp in de psychologie (vgl. Locke & Latham, 2006). Het is aangetoond dat de prestaties het hoogst zijn wanneer doelen zo specifiek mogelijk zijn en uitdagend zonder onhaalbaar te lijken. The Definition of Done is echter geen methode om doelen te stellen (maar als het gebruikt moet worden, is het wel een methode om doelen te stellen). Ondersteuning bij het stellen van doelen Als je hulp nodig hebt, helpen we je graag); het is eerder een kwestie van criteria waaraan moet worden voldaan om het doel te bereiken. 

Deze criteria zijn belangrijk om een gemeenschappelijk begrip in het team te creëren. Een begrip van wat elk teamlid moet bereiken om het gemeenschappelijke doel te bereiken. Het gaat dus om individuele prestaties die uiteindelijk samen een teamprestatie vormen.

Als we de DoD-kwestie bekijken vanuit het gezichtspunt van de producteigenaar, komen er heel andere problemen aan het licht. Als niet duidelijk is gedefinieerd wanneer een productstap als voltooid wordt beschouwd, kan dit leiden tot onenigheid met de klant wanneer het product aan hem wordt gepresenteerd. Als dit gebeurt en een onaf product wordt gepresenteerd, wordt de mogelijkheid van feedback van de klant geblokkeerd. 

: Voortdurende verbetering

Omdat een Definition of Done geen statisch concept is en voortdurend kan en moet evolueren of veranderen, biedt het het team ook de mogelijkheid om te leren. Als het team zich aan het einde van een sprint realiseert dat het niet kon voldoen aan de criteria van de Definition of Done, kunnen de teamleden ofwel de Definition of Done aanpassen aan de werkelijke prestaties, of het team trekt conclusies voor de volgende sprint en verandert zijn eigen manier van werken.

Probeer Echometer nu gratis uit & doe nieuwe inspiratie op voor je retrospectives!

Test Echometer gratis

Deze reflecties op de Definition of Done moeten door het team worden gedaan tijdens de retrospective. Mogelijk Echometer ArtikelenDe vragen die je ter voorbereiding kunt stellen zijn 

We hebben duidelijke Definities van Gedaan voor onze vereisten.

Meestal weet ik waar we staan in het bereiken van onze gemeenschappelijke doelen.

Doelen: Mijn doelen zijn afgestemd op de doelen van mijn collega’s.

Het team beschikt over alle vaardigheden die we nodig hebben om ons doel te bereiken.

Ze vragen zich niet alleen af of er überhaupt wel een Definition of Done in het team is, maar ook hoe het gesteld is met de transparantie, autonomie en rolduidelijkheid in het team.

Je kunt de volledige artikelenpool vinden in onze Retro gereedschap.

Hoe kan ons team het gedane definiëren? Een voorbeeld van een workshop

We hebben je laten zien wat een Definition of Done is en waarom ze belangrijk zijn voor effectieve samenwerking in Scrum teams. Maar als jouw team nog geen DoD heeft gemaakt, vraag je je waarschijnlijk af hoe het werkt. 

In principe is het belangrijk dat het team de tijd neemt om het document op te stellen. Uiteindelijk moet er een document uitkomen waarmee elk teamlid zich kan identificeren en dat niet alleen wordt gezien als een noodzakelijk kwaad. Daarom raden we een workshopachtig format aan met de Scrum Master als moderator. Elk teamlid moet nadenken over welke criteria belangrijk zijn voor de voltooiing van het product en het team kan deze gedachten vervolgens samenvatten. Analoog hieraan hebben we een workshopformat ontwikkeld voor het stellen van doelen. Neem een kijkjeom ideeën op te doen voor jouw Definition of Done workshop! 

De voltooide DoD kan worden gebruikt in retrospectives, bijvoorbeeld in de vorm van het Definition-of-Done stoplicht:  

1. Schrijf je criteria voor de Definitie van Gedaan onder elkaar.
2. Teken een rood, een geel en een groen vierkant naast elk vierkant.
3. Voor elk item in de Definition of Done markeert elk teamlid of het goed, matig of slecht is geïmplementeerd in de laatste sprint. 
4. Bespreek de drie met de meeste vermeldingen in het rode gebied.
5. Pas je definitie van Klaar aan als dat nodig is.

Conclusie - Klaar?

Een paar afsluitende woorden: Er bestaat niet zoiets als eindelijk “klaar” in de agile omgeving. Klaar betekent alleen dat iets voorlopig af is, maar verdere aanpassingen en verbeteringen kunnen en moeten op elk moment volgen. Dit is een van de vele mooie aspecten van agile werken: voortdurende verbetering. 

Bijzonder spannend: soms zijn punten “klaar” totdat de klant naar voren komt en de hele oplossing in twijfel trekt, waardoor je basis van aannames over de behoeften van de klant aan het wankelen wordt gebracht. In zulke situaties wordt duidelijk of het team echt prioriteit heeft gegeven aan de voordelen voor de klant boven de voortgang in het ticketsysteem.

Een duidelijke definitie van gedaan kan conflicten voorkomen en je prestaties verhogen. Als je geïnteresseerd bent in meer manieren om dit doel te bereiken, moet je ook eens kijken naar ons artikel over de verbazingwekkende waarheid achter de agile mindset kijken. Of verrijk je terugblikken door rekening te houden met de nieuwste wetenschappelijke bevindingen in de psychologie.

Precies met deze belofte hebben we onze retro tool Echometer ontwikkeld. Als je geïnteresseerd bent in hoe (en of) Echometer werkt, lees dan Holger’s ervaringsverslag met onze tool:

Wil je je team naar een nieuw prestatieniveau tillen? Onze Retro Tool kan je daarbij helpen. Hier zijn Holger’s ervaringen ermee:

Holger’s veldrapport over het Remote Retro Tool

Veelgestelde vragen over de Definitie van Done

Wat hoort in een Definitie van Done?

In een Definitie van Done horen alle kwaliteitscriteria waaraan een increment moet voldoen, zodat het bruikbaar is. Typische voorbeelden zijn vervulde acceptatiecriteria, code review, tests, veiligheidscontrole, documentatie en de technische mogelijkheid tot levering. Welke punten gelden, beslist het team voor zijn productcontext.

Wie maakt de Definitie van Done in Scrum?

Het Scrum-team ontwikkelt en onderhoudt de Definitie van Done gezamenlijk. Ze zou niet door één enkele rol als controlelijst moeten worden opgelegd. Organisaties kunnen minimumstandaarden vastleggen, maar het team moet ze begrijpen en in het dagelijks werk kunnen toepassen.

Wat is het verschil tussen Definitie van Done en Definitie van Ready?

De Definition of Done beschrijft wanneer een increment klaar en bruikbaar is. Een Definition of Ready kan daarentegen criteria bevatten voor de voorbereiding van een werkitem, maar is geen officieel Scrum-artefact en mag niet worden gebruikt om verantwoordelijkheid of feedbackloops te verschuiven.

Voorbeeld uit de praktijk: Onze interne Definition of Done bij Echometer

Een Definition of Done hoeft niet op te houden bij code en tests. Echometer hanteert intern een uitgebreidere standaard die naast functionaliteit ook rekening houdt met UX, onderhoudbaarheid, observeerbaarheid en de voorbereiding van de release. Het volgende voorbeeld laat zien hoe een team zijn eigen kwaliteitscriteria concreet en toetsbaar kan maken:

Gebied	Voorbeeldcriteria
Functionaliteit	De gespecificeerde functie werkt, typische edge cases zijn gecontroleerd, er zijn geen bekende fouten, onvoltooide functies zijn beveiligd via een feature flag en relevante gebruiksgegevens worden vastgelegd.
UX	Er is rekening gehouden met lege toestanden, laadstatussen, machtigingen, foutafhandeling, lokalisatie en responsieve weergave.
Onderhoudbaarheid	Coding guidelines en relevante conventies worden nageleefd, onnodige code en bewust achtergelaten technische schuld zijn vermeden, en belangrijke informatie voor monitoring en debugging is aanwezig.
Deployment	De wijziging is productief uitgerold of bewust voorbereid via een feature flag, release notes zijn aangevuld en betrokken stakeholders worden indien nodig geïnformeerd.

Dit voorbeeld is natuurlijk geen universeel sjabloon. Je kunt het echter als basis gebruiken, aanvullen met eigen definities, regelmatig evalueren en als levend document verder ontwikkelen.

Bronnen

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x