Wat is de Definition of Done?
Heb je ooit iets opgeleverd om er vervolgens achter te komen dat het eigenlijk nog niet af was? De Definition of Done (DoD) brengt duidelijkheid in een van de belangrijkste gedeelde afspraken die een team kan hebben. Het schept een helder, gezamenlijk begrip van de criteria waaraan voldaan moet worden voordat een stuk werk — een user story, een feature of een hele sprint — als echt voltooid kan worden beschouwd. Door deze verwachtingen expliciet te maken, verminderen teams herwerk, verbeteren ze de kwaliteit en creëren ze een betrouwbare, herhaalbare standaard voor oplevering. Geworteld in agile- en Scrum-praktijken fungeert de Definition of Done als een kwaliteitschecklist waar iedereen mee instemt voordat het werk begint. Het haalt het giswerk weg uit de "is dit af?"-gesprekken en helpt teams de valkuil te vermijden van verborgen werk dat naar toekomstige sprints wordt meegesleept. Of je nu voor het eerst "done" definieert of een bestaande afspraak herziet, deze gezamenlijke sessie moedigt elke stem aan om bij te dragen — van ontwikkelaars en testers tot ontwerpers en product owners — zodat het resultaat het perspectief van het hele team weerspiegelt. Het uitvoeren van deze sessie in TeamRetro maakt het eenvoudig om de criteria die er het meest toe doen voor jouw team vast te leggen, te bespreken, te groeperen en te prioriteren. Het resultaat is een levend document dat meegroeit met de volwassenheid en standaarden van je team. Dat leidt tot voorspelbaardere oplevering, minder verrassingen tijdens de review en een gedeeld gevoel van verantwoordelijkheid dat de kwaliteit van alles wat je oplevert verhoogt. Lees meer over het concept in de <a href="https://www.scrum.org/resources/blog/done-understanding-definition-done" target="_blank" rel="noopener noreferrer">Scrum.org-gids over de Definition of Done</a>.
Definition of Done samenwerkingsformat
Kwaliteitscriteria
Aan welke kwaliteitsnormen moet werk voldoen om af te zijn?
Dit onderwerp legt de technische en kwaliteitsmaatstaven vast waaraan elk stuk werk moet voldoen voordat het als voltooid wordt beschouwd. Moedig het team aan om na te denken over codekwaliteit, testdekking, prestaties en standaarden. Stel onderzoekende vragen zoals 'Wat zou ons het vertrouwen geven dat dit niet kapotgaat in productie?' om impliciete verwachtingen aan het licht te brengen en ze om te zetten in expliciete, meetbare criteria.
Documentatie & Communicatie
Wat moet er gedocumenteerd of gedeeld worden voordat iets af is?
Gebruik dit onderwerp om de verwachtingen rond kennisdeling en documentatie aan het licht te brengen die het team op één lijn houden en toekomstige verwarring verminderen. Vraag deelnemers om na te denken over wie van de wijziging op de hoogte moet zijn en welke artefacten zouden moeten bestaan. Dit is vaak het meest over het hoofd geziene onderdeel van done, dus moedig eerlijke reflectie op eerdere hiaten aan.
Testen & Validatie
Hoe controleren we of het werk daadwerkelijk werkt?
Dit onderwerp richt zich op de verificatiestappen die bewijzen dat het werk aan de eisen voldoet en zich gedraagt zoals verwacht. Begeleid het team om verder te denken dan geautomatiseerde tests en ook handmatige, verkennende en acceptatietests mee te nemen. Moedig hen aan te bepalen wie het werk valideert en in welke omgeving.
Deployment & Gereedheid
Wat moet waar zijn om het werk veilig vrij te geven?
Hier definieert het team wat het betekent dat werk klaar is voor release en live staat voor gebruikers. Stimuleer discussie over deployment, monitoring, rollback-plannen en operationele gereedheid. Dit helpt teams het veelvoorkomende gat tussen 'code compleet' en 'daadwerkelijk waarde leveren' te vermijden.
Wanneer dient u deze retrospective te gebruiken?
- Wanneer een nieuw team wordt gevormd en vanaf het begin gedeelde kwaliteitsnormen moet vaststellen.
- Wanneer werk regelmatig wordt heropend of bugs in productie sluipen, wat duidt op onduidelijke voltooiingscriteria.
- Voorafgaand aan een nieuw project of sprint om ervoor te zorgen dat iedereen het eens is over hoe 'af' eruitziet.
- Bij het inwerken van nieuwe leden die de kwaliteitsverwachtingen van het team moeten begrijpen.
- Tijdens een retrospective wanneer het team inconsistentie ontdekt in hoe werk als voltooid wordt beschouwd.
Voorstellen voor ijsbrekers
- Als 'done' een persoonlijkheid had, hoe zou die dan zijn — perfectionist, pragmaticus of last-minute held?
- Wat is het meest verrassende dat je ooit ontdekte dat eigenlijk NIET af was?
Ideeën en tips voor uw retrospectievevergadering
- Creëer de Definition of Done samen met het hele team zodat iedereen zich eigenaar voelt — voorkom dat één persoon de standaarden dicteert.
- Houd de criteria realistisch en haalbaar; een te ambitieuze DoD die nooit wordt gehaald, ondermijnt het doel ervan.
- Maak elk criterium specifiek en verifieerbaar zodat er geen onduidelijkheid bestaat over de vraag of eraan is voldaan.
- Behandel de Definition of Done als een levend document en herzie het periodiek naarmate de standaarden en tooling van je team evolueren.
- Moedig stillere teamleden aan om bij te dragen door iedereen tijd te geven om zelfstandig ideeën toe te voegen vóór de groepsdiscussie.
- Maak onderscheid tussen de Definition of Done en acceptatiecriteria — de DoD geldt voor al het werk, terwijl acceptatiecriteria storyspecifiek zijn.