Kwaliteitscriteria

Aan welke kwaliteitsnormen moet werk voldoen om af te zijn?

Alle code is door peers beoordeeld en goedgekeurd door minstens één andere ontwikkelaar.
De dekking van unittests voldoet aan onze afgesproken drempel van 80% of hoger.
Er staan geen kritieke of zeer ernstige bugs meer open.
Documentatie & Communicatie

Wat moet er gedocumenteerd of gedeeld worden voordat iets af is?

Gebruikersgerichte documentatie is bijgewerkt om de wijziging te weerspiegelen.
Release notes en changelog-vermeldingen zijn compleet.
API-documentatie weerspiegelt nieuwe of gewijzigde endpoints.
Testen & Validatie

Hoe controleren we of het werk daadwerkelijk werkt?

Aan alle acceptatiecriteria van de user story is voldaan.
Handmatige tests zijn uitgevoerd op ondersteunde browsers en apparaten.
Feature is door de product owner gevalideerd voordat deze werd afgesloten.
Deployment & Gereedheid

Wat moet waar zijn om het werk veilig vrij te geven?

Feature is gedeployd naar productie of staat achter een feature flag.
Monitoring en alerting zijn geconfigureerd voor de nieuwe functionaliteit.
Er is een rollback- of herstelplan klaar als er iets misgaat.

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.

Veelgestelde vragen

Wat is een Definition of Done in agile?
Een Definition of Done is een gedeelde, expliciete set criteria waaraan een stuk werk moet voldoen voordat het als voltooid wordt beschouwd. Het creëert een consistente kwaliteitsstandaard binnen het team en vermindert de onduidelijkheid over wat 'af' betekent.
Hoe verschilt de Definition of Done van acceptatiecriteria?
De Definition of Done geldt voor alle werkitems als een universele kwaliteitschecklist, terwijl acceptatiecriteria specifiek zijn voor een individuele user story en de unieke eisen ervan beschrijven. Aan beide moet worden voldaan om werk echt voltooid te laten zijn.
Wie moet betrokken zijn bij het opstellen van de Definition of Done?
Het hele team moet samenwerken, inclusief ontwikkelaars, testers, ontwerpers en de product owner. Gedeeld eigenaarschap zorgt ervoor dat de criteria realistisch, volledig en door iedereen gerespecteerd zijn.
Hoe vaak moeten we onze Definition of Done bijwerken?
Behandel het als een levend document en herzie het periodiek — bijvoorbeeld tijdens retrospectives of naarmate je tooling, vaardigheden en kwaliteitsnormen volwassen worden. Veel teams herzien het elke paar sprints.
Hoe lang duurt het om een Definition of Done op te stellen?
Een eerste sessie duurt doorgaans 45 tot 90 minuten, afhankelijk van de teamgrootte en hoeveel afstemming er al bestaat. Volgende herzieningen zijn meestal veel korter.

Bent u nieuw op het gebied van retrospectives? Lees dan onze handleiding over het houden van een retrospective →