Definitie van ‘klaar’

De definitie van ‘klaar’ is één checklist voor het hele team: de norm waaraan elk verhaal moet voldoen voordat het als voltooid wordt beschouwd. Acceptatiecriteria gelden per verhaal; de definitie van ‘klaar’ is algemeen geldend. Door deze twee met elkaar 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 klaar is“ en „het is daadwerkelijk klaar voor release“. De definitie van ‘klaar’ dicht die kloof. U komt dit eenmalig overeen en handhaaft het elke sprint, ongeacht wat er in een afzonderlijke user story staat. Zonder deze definitie is „klaar“ een persoonlijke mening, en komt het verschil naar voren tijdens de demo, of erger nog, in de productieomgeving.

Een checklist voor de definitie van ‘voltooid’ (voorbeeld)

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 fouten 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 rooktests.
• De producteigenaar heeft dit goedgekeurd.

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

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 geven antwoord op de vraag „hebben we het juiste gebouwd?”. De definitie van „klaar” is globaal en geeft antwoord op de vraag „is ons werk ooit klaar voor uitrol?”. 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’ zorgt ervoor dat een story in de sprint wordt opgenomen: klein genoeg, duidelijk genoeg, ingeschat. De definitie van ‘af’ zorgt ervoor dat het voltooide werk uit de sprint wordt gehaald. ‘Klaar’ heeft betrekking op de story; ‘af’ heeft betrekking op het werk. Teams die slechts één van beide hanteren, hanteren meestal ‘klaar’ (omdat verhalen die nog niet klaar zijn veel aandacht trekken) en laten ‘afgerond’ stilletjes op de achtergrond raken; zo stapelen de overgedragen en ‘voor 90% voltooide’ verhalen zich op.

De drie checklists lopen niet langer in elkaar over zodra u inziet wat er bij elk ervan 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 gemaakt?"	"Kan het worden verzonden?”
Eigendom van	Team, samen met de producteigenaar	Productverantwoordelijke, samen met het team	Het team

Wie bepaalt wat ‘af’ is?

Het team stelt het op; het team ziet erop toe dat het wordt nageleefd. De scrummaster begeleidt het proces en de producteigenaar geeft input over de acceptatiemaatstaf, 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.

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, loopt velocity op: 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 story. De definitie van ‘klaar’ vormt een controlepunt voor het team. Houd deze kort genoeg zodat u ze daadwerkelijk kunt handhaven. Een controlepunt dat niet wordt gehandhaafd, is slechts papierwerk.

Veelgestelde vragen

Wat is de definitie van ‘klaar’ binnen agile?

De definitie van ‘klaar’ bestaat uit éé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; voor elk verhaal geldt dezelfde toetsingsfase. 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 stuk 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 story 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 ‘klaar’ en de definitie van ‘afgerond’?

De „Ready”-criteria markeren de start van de sprint; dit is de drempel die een user story moet halen voordat het team zich eraan toewijdt. De „Done”-criteria markeren het einde van de sprint; dit is de drempel die het voltooide werk moet halen voordat het wordt uitgeleverd. Bij „Ready” gaat het erom dat de user story goed is opgesteld; bij „Done” gaat het erom dat het werk klaar is voor uitlevering.

Wie stelt de definitie van ‘klaar’ vast?

Het ontwikkelingsteam is hiervoor verantwoordelijk, doorgaans onder begeleiding van de scrummaster. De producteigenaar heeft inspraak bij het vaststellen van 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-schatting: de complete gids: hier vindt u alle informatie hierover.
• Acceptatiecriteria: de test per verhaal waarmee de definitie van ‘klaar’ vaak wordt verward.
• Definitie van ‘ready’: de doorkoop aan het andere uiteinde van de sprint.
• Fouten bij Planning Poker: hoe een te ruim opgevat ‘klaar’ de velocity opblaast.