Definitie van ‘klaar’ (DoD): checklist en voorbeelden

De definitie van ‘klaar’ (DoD) is de korte checklist waarmee een team overeenkomt dat elk verhaal aan moet voldoen voordat het als voltooid wordt beschouwd: beoordeeld, getest, samengevoegd, geïmplementeerd, geaccepteerd. Het is één standaard voor het gehele team. Acceptatiecriteria gelden per story; de definitie van ‘klaar’ is algemeen. Door deze twee te verwarren, krijgt ‘klaar’ stilletjes de betekenis van ‘het werkt op mijn computer’.

Elk team heeft wel eens de kloof ervaren tussen „de ontwikkelaar zegt dat het af is“ en „het is daadwerkelijk klaar voor uitrol“. De definitie van ‘af’ dicht die kloof. U komt deze definitie eenmalig overeen en handhaaft deze bij elke sprint, ongeacht wat er in een afzonderlijke user story gebeurt. Zonder deze definitie is „klaar“ een persoonlijke mening, en komt het verschil aan het licht tijdens de demo, of erger nog, in de productieomgeving.

Wat de definitie van ‘klaar’ in Scrum inhoudt

De Scrum Guide omschrijft het als „een formele beschrijving van de toestand van het Increment op het moment dat het voldoet aan de kwaliteitsnormen die voor het product vereist zijn.” Eenvoudig gezegd is de definitie van ‘klaar’ de toezegging die verbonden is aan het Increment, een van de drie Scrum-artefacten. Werk dat hieraan voldoet, wordt onderdeel van het Increment. Werk dat hier niet aan voldoet, kan niet worden vrijgegeven of getoond tijdens de sprintreview; het gaat terug naar de productbacklog.

Indien uw organisatie al een definitie van ‘klaar’ heeft vastgesteld, hanteert elk team deze als minimum en kan het hieraan aanvullingen doen. Indien dit niet het geval is, stelt het team zelf een definitie op. Dit principe is niet beperkt tot Scrum: Kanban-teams stellen vaak dezelfde lijst op als richtlijn voor het verplaatsen van werk naar hun laatste kolom.

Voorbeelden van de definitie van ‘klaar’

Voorbeeld van een checklist voor de definitie van ‘klaar’: een softwareteam

Een praktisch uitgangspunt voor een team dat een webapp oplevert:

• Aan de acceptatiecriteria is voldaan en deze zijn geverifieerd.
• De code is gecontroleerd en samengevoegd met de hoofdtak.
• Geautomatiseerde tests zijn geschreven en geslaagd; er zijn geen nieuwe onbetrouwbare tests.
• Er zijn geen bekende regressies of openstaande kritieke bugs met betrekking tot dit onderdeel.
• De documentatie en het wijzigingslogboek zijn bijgewerkt voor zover de wijziging gevolgen heeft voor de gebruiker.
• Geïmplementeerd in de staging-omgeving en onderworpen aan een smoke-test.
• De producteigenaar heeft dit goedgekeurd.

Neem dit over en pas het vervolgens aan aan wat uw team daadwerkelijk zal handhaven. Een definitie van ‘klaar’ met een criterium dat niemand controleert, is erger dan een korte definitie. Het zorgt ervoor dat het team de hele lijst als louter decoratief gaat beschouwen. Beperk het tot één scherm en zorg ervoor dat elk punt toetsbaar blijft.

Voorbeeld van de definitie van ‘klaar’: een team dat geen code uitbrengt

Hetzelfde principe geldt voor een marketing-, content- of ontwerpteam. De definitie van ‘klaar’ voor een contentteam zou als volgt kunnen luiden:

• Aan de acceptatiecriteria van de opdracht is voldaan.
• Bewerkt door iemand anders dan de auteur.
• Feiten, cijfers en links zijn gecontroleerd.
• De basisprincipes van toegankelijkheid zijn in orde: alt-tekst, volgorde van koppen, leesbaar contrast.
• Goedgekeurd door degene die hierom heeft verzocht.
• Gepubliceerd of overgedragen, en vastgelegd op een plek waar het team het kan inzien.

Story-, sprint- en releaseniveaus

Scrum vereist één definitie van ‘klaar’ voor het increment. In de praktijk groeperen veel teams de controles op basis van de context waarin deze van nature plaatsvinden:

Niveau	Van toepassing op	Typische artikelen
Verhaal	Elk backlog-item	De code is gecontroleerd, de tests zijn geslaagd, aan de acceptatiecriteria is voldaan en de productverantwoordelijke heeft het goedgekeurd
Sprint	De Increment in zijn geheel	Geïntegreerd in de hoofdbranch, regressietestsuccesvol, geïmplementeerd in de staging-omgeving
Persbericht	Wat de klanten bereikt	Release-opmerkingen opgesteld, beveiligings- en prestatiecontroles uitgevoerd, ondersteuning geïnformeerd

Gebruik het verhaal als basis voor de kernlijst. Als een controle pas bij de release kan plaatsvinden, vermeld dat dan ook op de lijst, zodat niemand een verhaal als voltooid markeert in de veronderstelling dat iemand anders deze omissie later wel zal opmerken.

Hoe stelt u een ‘definition of done’ op?

1. Begin bij wat steeds ontglipt. Kijk eens naar de laatste paar sprints: de fouten die na „done“ werden ontdekt, de stories die werden teruggestuurd, de overgedragen taken. Elk daarvan wijst op een ontbrekende schakel.
2. Stel het samen met het hele team op. De mensen die het werk uitvoeren, komen het tijdens één sessie overeen, waarbij de scrummaster de leiding heeft en de producteigenaar aanwezig is. Een lijst die van buitenaf wordt opgelegd, zal het team onder druk van deadlines niet verdedigen.
3. Zorg ervoor dat elke regel controleerbaar is. „Getest” is een indruk; „geautomatiseerde tests geschreven en geslaagd in CI” is een controle. Als twee mensen het oneens zouden kunnen zijn over de vraag of aan een regel is voldaan, herschrijf deze dan.
4. Beperk het tot wat u op dit moment daadwerkelijk gaat handhaven. We zouden beginnen met vijf tot acht regels. Voeg de ambitieuze doelstellingen pas toe wanneer het team deze daadwerkelijk kan halen.
5. Plaats het daar waar het werk plaatsvindt. Een checklist in het ticketsjabloon of in de kolom „voltooid” van het bord wordt daadwerkelijk gebruikt. Een pagina op de wiki raakt in de vergetelheid.
6. Evalueer dit in de retrospective. Wanneer dezelfde lacune twee keer over het hoofd wordt gezien, voeg dan een regel toe. Wanneer een regel wordt aangevinkt zonder dat iemand deze heeft gecontroleerd, vraag dan of deze nog steeds op zijn plaats is.

Definitie van ‘klaar’ versus acceptatiecriteria

Dit is het onderscheid waar teams het vaakst over struikelen. De acceptatiecriteria voor een inlogverhaal zijn specifiek voor het inloggen: met de juiste inloggegevens komt u op het dashboard terecht, bij drie verkeerde pogingen wordt het account geblokkeerd. De definitie van ‘klaar’ (gecontroleerd, getest, geïmplementeerd) is identiek voor het inlogverhaal, het zoekverhaal en het factureringsverhaal. Criteria zijn lokaal en beantwoorden de vraag „hebben we het juiste gebouwd?“ De definitie van „klaar“ is globaal en beantwoordt de vraag „is er überhaupt werk van ons dat ooit kan worden opgeleverd?“ Een verhaal is pas voltooid als het beide toetsingen doorstaat.

Definitie van ‘klaar’ versus definitie van ‘afgerond’

Het zijn boekensteunen, geen symmetrische tweelingen. De definitie van ‘klaar’ laat een story binnen de sprint toe: klein genoeg, duidelijk genoeg, ingeschat. De definitie van ‘af’ laat het voltooide werk uit de sprint. ‘Klaar’ heeft betrekking op de story; ‘af’ heeft betrekking op het werk. Teams die slechts één van beide hebben, hanteren meestal ‘ready’ (omdat ongereed verklaarde verhalen veel aandacht trekken) en laten ‘done’ stilletjes op de achtergrond raken; zo stapelen zich overgedragen en ‘voor 90% voltooide’ verhalen op.

De drie checklists lopen niet langer in elkaar over zodra u inziet wat er bij elk van hen moet worden gecontroleerd:

	Definitie van ‘klaar’	Acceptatiecriteria	Definitie van ‘klaar’
Toepassingsgebied	Wereldwijd, elk verhaal	Lokaal: dit verhaal	Wereldwijd, elk verhaal
Poorten	De start van de sprint	De uitkomst van het verhaal zelf	De sprint beëindigen
Antwoorden	”Kunnen we hiermee beginnen?"	"Hebben wij het juiste gebouwd?"	"Kan het worden verzonden?”
Eigendom van	Team, samen met de producteigenaar	Productverantwoordelijke, samen met het team	Het team

Wie bepaalt wat ‘af’ betekent?

Het team stelt het op; het team ziet erop toe dat het wordt nageleefd. De scrummaster begeleidt het proces en de producteigenaar geeft zijn mening over de acceptatienorm, maar de ontwikkelaars bepalen wat er technisch gezien nodig is om iets als „klaar“ te beschouwen, want een vaag gedefinieerd „klaar“ is een schuld die zij moeten aflossen, niet het management. Bespreek het opnieuw tijdens een retrospective wanneer dezelfde lacune steeds weer terugkomt; dat is het teken dat er een grens ontbreekt.

Hoe de definitie van ‘klaar’ uw schattingen beïnvloedt

Storypoints geven de omvang van het werk weer tot het moment dat het „af” is, niet tot het moment dat de „code voltooid” is. De definitie van „af” is dus in elke schatting verwerkt. Voeg een regel toe als „prestaties getest” en elke story wordt iets omvangrijker. Wanneer de lijst verandert, moet u uw referentiestories tijdens de volgende planningssessie opnieuw controleren, anders zal de velocity dalen om een reden die niemand kan benoemen.

Wat gaat er mis?

De definitie van ‘klaar’ wordt een poster. Deze wordt op de teamwiki opgehangen, tijdens de introductie voorgelezen en onder druk van deadlines genegeerd: „We schrijven de tests wel in de volgende sprint.” Twee sprints later is de testschuld structureel geworden en is de definitie niet meer dan een fictie. Wanneer „klaar“ vaag is, wordt de velocity opgeblazen: het team boekt punten voor werk dat niet echt leverbaar is, en de prognose verliest stilletjes elke betekenis.

De oplossing ligt niet in een langere lijst, maar in een kortere lijst waar het team strikt aan vasthoudt. Een definitie van ‘afgerond’ is slechts zo concreet als het verhaal dat u bereid bent niet als afgerond te markeren omdat het aan één criterium niet voldeed.

De acceptatiecriteria vormen een controlepunt voor het verhaal. De definitie van ‘klaar’ vormt een controlepunt voor het team. Houd deze kort genoeg zodat u er daadwerkelijk toezicht op kunt houden. Een controlepunt waarop geen toezicht wordt gehouden, is slechts papierwerk.

Veelgestelde vragen

Wat is de definitie van ‘klaar’ in agile?

De definitie van ‘klaar’ (DoD) is één enkele checklist waaraan elk verhaal moet voldoen voordat het als voltooid wordt beschouwd: doorgaans getest, gecontroleerd, samengevoegd, gedocumenteerd en geïmplementeerd in de staging-omgeving. Het is één gezamenlijke norm voor het hele team, geen afzonderlijke lijst per verhaal, en deze is bedoeld om ervoor te zorgen dat ‘klaar’ telkens hetzelfde betekent wanneer iemand dit zegt.

Wat is het verschil tussen de definitie van ‘klaar’ en de acceptatiecriteria?

De definitie van ‘klaar’ is algemeen van toepassing; het is voor elk verhaal dezelfde toetssteen. Acceptatiecriteria zijn lokaal van aard en specifiek voor één verhaal. Acceptatiecriteria geven aan wat deze functie moet doen; de definitie van ‘klaar’ geeft aan wat ‘klaar voor levering’ inhoudt voor elk werk dat het team produceert. Een verhaal moet aan beide voldoen.

Wat is een checklist voor de definitie van ‘klaar’?

Een korte, duidelijke lijst met voorwaarden die voor elk verhaal gelden: code gecontroleerd en samengevoegd, tests geschreven en geslaagd, geen bekende regressies, documentatie bijgewerkt, geïmplementeerd in een testomgeving en goedgekeurd door de product-owner. De exacte punten kunnen per team verschillen, maar de lijst moet op één scherm passen en elke regel moet controleerbaar zijn.

Wat is het verschil tussen de definitie van ‘gereed’ en de definitie van ‘afgerond’?

De ‘Ready’-controlepunt markeert de start van de sprint; het is de drempel die een story moet halen voordat het team zich eraan wijdt. Het ‘Done’-controlepunt markeert het einde; het is de drempel die het voltooide werk moet halen voordat het wordt uitgebracht. Bij ‘Ready’ gaat het erom dat de story goed is opgesteld; bij ‘Done’ gaat het erom dat het werk klaar is voor uitgave.

Hoe stelt u een ‘definition of done’ op?

Begin met wat steeds weer over het hoofd wordt gezien: de fouten, het herstelwerk en de achterstanden uit de afgelopen paar sprints. Stem de lijst af met het hele team, formuleer elke regel zo dat er een ja-of-nee-antwoord op mogelijk is, beperk de lijst tot wat u daadwerkelijk gaat handhaven en plaats deze op de plek waar het werk plaatsvindt, zoals in het ticketsjabloon. Bekijk de lijst vervolgens opnieuw tijdens de retrospective wanneer er iets door de mazen van het net glipt.

Wie stelt de definitie van ‘klaar’ vast?

Het ontwikkelingsteam draagt de verantwoordelijkheid hiervoor, doorgaans onder leiding van de scrummaster. De producteigenaar heeft inspraak in de acceptatiecriteria, maar de mensen die het werk uitvoeren, bepalen wat er technisch gezien nodig is om iets als „klaar“ te beschouwen, omdat zij degenen zijn die de prijs betalen wanneer dit te vaag wordt gedefinieerd.

Aanbevolen lectuur

• Agile-inschatting: de complete gids: hier vindt u alle informatie.
• Acceptatiecriteria: de test per verhaal waarmee de definitie van ‘klaar’ vaak wordt verward.
• Definitie van ‘klaar’: de doorkoer aan het andere eind van de sprint.
• Fouten bij Planning Poker: hoe een te ruim opgevat ‘klaar’ de velocity opdrijft.