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. Door deze twee door elkaar te halen, 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 release“. De definitie van ‘af’ dicht die kloof. U komt hier één keer overeen en handhaaft dit elke sprint, ongeacht wat er in een afzonderlijke user story gebeurt. Zonder deze definitie is „klaar“ een persoonlijke mening — en het verschil komt aan het licht 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 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 smoke-tests.
• 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 leidt ertoe dat het team de hele lijst als louter decoratief gaat beschouwen. Zorg ervoor dat het op één scherm past en dat elk punt toetsbaar 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’ — beoordeeld, 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 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 ‘ready’ (omdat verhalen die nog niet klaar zijn veel aandacht trekken) en laten ‘done’ stilletjes op de achtergrond raken — en zo stapelen de overgedragen verhalen en de verhalen die ‘voor 90% voltooid’ zijn zich op.

De drie checklists lopen niet langer in elkaar over zodra u ziet waarvoor elke checklist als voorwaarde fungeert:

	Definitie van ‘klaar’	Acceptatiecriteria	Definitie van ‘klaar’
Toepassingsgebied	Wereldwijd — elk verhaal	Lokaal — dit artikel	Wereldwijd — elk verhaal
Poorten	De start van de sprint	De afloop 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.

Wat gaat er mis?

De definitie van ‘klaar’ wordt een poster. Deze wordt op de teamwiki gepind, 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 verhaal. 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’ 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 norm 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 — dezelfde toetsingscriteria gelden voor elk verhaal. Acceptatiecriteria zijn specifiek — ze gelden voor één bepaald 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 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 „klaar” en de definitie van „afgerond”?

De „Ready“-poort markeert de start van de sprint — de drempel die een story moet halen voordat het team zich eraan wijdt. De „Done“-poort markeert het einde — 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.

Wie stelt de definitie van ‘klaar’ vast?

Het ontwikkelingsteam is hiervoor verantwoordelijk, doorgaans onder leiding 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 — want zij zijn degenen die de prijs betalen wanneer dit te vaag wordt gedefinieerd.

Aanbevolen lectuur

• Agile-inschatting: 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 doellijn aan het andere eind van de sprint.
• Fouten bij Planning Poker — hoe een te ruim opgevat ‘klaar’ de velocity opblaast.