Definition of Done, nut en noodzaak
De organisatie is begonnen met scrum en vandaag eindigt de eerste sprint. De sprint review start. Een van de ontwikkelaars neemt het woord. Trots vertelt hij dat de eerste user story is afgerond. Het betreft het toevoegen van een tweede telefoonnummer op het scherm. Hij laat het scherm zien waar dat tweede telefoonnummer op staat en vraagt akkoord van de stakeholders die aanwezig zijn. Het blijft enige tijd stil. Dan geeft een van de stakeholders aan dat hij de user story had ingediend en graag even achter het toetsenbord wil zitten om te testen. Daar willen de andere stakeholders niet op wachten. Iemand vraagt of er wel naar de performance is gekeken. Een tweede vraagt of de documentatie wel is bijgewerkt en de derde twijfelt of de veldnaam wel aan de naamgevingsstandaards voldoet. Na enige discussie besluit de product owner uiteindelijk deze user story aan te houden en daar in de volgende sprint review op terug te komen.
Herkenbaar? Dit is een voorbeeld van een organisatie die geen heldere Definition of Done (DoD) heeft afgesproken. Dat kan vervelende gevolgen hebben. In dit artikel lees je wat de DoD is, wat het verschil is met acceptatiecriteria, wat de voordelen van een goede DoD zijn, en wat de risico’s zijn bij het ontbreken ervan.
Wat is de Definition of Done?
Een Definition of Done (DoD) is een checklist met niet-functionele kwaliteitseisen die voor alle user stories gelden. Deze eisen kunnen bijvoorbeeld te maken hebben met documentatie die bijgewerkt moet worden, de te gebruiken standaards of de uit te voeren tests. Het kan wel voorkomen dat een eis voor een bepaalde user story niet relevant is, maar dat zou uit de formulering moeten blijken, zodat daar geen misverstanden over kunnen bestaan. Zo is de eis dat het datamodel bijgewerkt moet zijn, niet relevant als de user story geen mutatie op dit datamodel tot gevolg heeft.
Pas als een user story aan al de (relevante) eisen voldoet, is de userstory afgerond. In de sprint review hoeft dan alleen nog maar teruggekoppeld te worden dat aan al deze eisen is voldaan. Dit kan door de product owner vooraf geverifieerd worden.
Definition of Done versus acceptatiecriteria
De DoD moet niet verward worden met de acceptatiecriteria die bij de user story zijn opgenomen. In bovenstaand voorbeeld zou een acceptatiecriterium opgenomen kunnen zijn dat het niet mogelijk moet zijn om letters in het telefoonnummer op te nemen. De acceptatiecriteria zijn functioneel van aard en alleen van toepassing voor die ene user story, terwijl de DoD niet functioneel is en voor alle user stories geldt. Een ander verschil is dat de product owner verantwoordelijk is voor de definiëring van de acceptatiecriteria, en het scrumteam als geheel voor het definiëren van de DoD. Dat wil overigens niet zeggen dat de product owner of het scrumteam dat helemaal zelfstandig bepaalt; de acceptatiecriteria komen vaak van de gebruikers en de DoD vaak ook van andere stakeholders zoals beheerders. Maar zij zijn wel verantwoordelijk dat die definiëring er is.
Acceptatiecriteria |
Definition of Done |
Gelden voor 1 specifieke user story |
Geldt voor alle user stories |
Functioneel |
Niet functioneel |
Definiëring verantwoordelijkheid product owner |
Definiëring verantwoordelijkheid scrumteam |
Een userstory moet zowel aan de acceptatiecriteria als aan de DoD voldoen.
De voordelen van een goede DoD
Een goede DoD heeft een aantal voordelen:
- Vaste kwaliteit: De stakeholders kunnen erop vertrouwen dat elke user story die wordt opgeleverd aan dezelfde kwaliteitseisen voldoet.
- Betere omvangschatting: Tijdens de refinement worden de user stories op de backlog uitgewerkt. Daarbij wordt ook de omvang van de user stories ingeschat. Hierbij kan worden meegewogen of er voor die user story niet-functionele eisen uit de DoD relevant zijn die de omvang verhogen, bijvoorbeeld omdat het een interface tussen twee applicaties betreft en in de DoD staat dat daarbij ook altijd een ketentest uitgevoerd moet worden.
- Betere sprint planning: Aan het begin van een sprint, tijdens de sprintplanning, worden per user story de uit te voeren taken bepaald. De kwaliteitseisen uit de DoD leiden vaak tot taken, bijvoorbeeld het aanpassen van documentatie of het opstellen van testscripts ten behoeve van de ketentest. Als de DoD van tevoren bekend is, kunnen de taken ook van tevoren gepland worden en is de kans groter dat die tijdig afgerond kunnen worden. Ook worden er dan niet meer user stories in scope getrokken dan het team aankan.
- Efficiëntere sprint review: Tijdens de sprint review hoeft de product owner alleen maar te bevestigen dat de betreffende user story aan alle criteria van de DoD voldoet. Deze hoeven niet meer in detail besproken te worden. Er hoeven tijdens de sprint review zelf ook geen tests plaats te vinden. Als in de DoD staat dat de stakeholder die de user story heeft ingebracht deze moet accepteren, zal dit zijn ingepland en zal hij dat voor de sprint review al gedaan hebben.
De risico’s van het ontbreken van een heldere DoD
Als de DoD niet helder of zelfs helemaal niet geformuleerd is, kan dat vervelende gevolgen hebben. Zo kunnen onderstaande risico’s ontstaan:
- Documentatie wordt niet goed bijgewerkt. Om de deadline te halen bestaat de neiging om het bijwerken van de documentatie door te schuiven, of zelfs helemaal achterwege te laten. De gebruiker merkt daar in eerste instantie niets van, maar als de documentatie achterloopt, kan dat impact hebben op de beheersbaarheid en zullen incidenten minder snel opgelost worden en changes meer tijd kosten.
- De software wordt met onvoldoende kwaliteit opgeleverd. Als in de DoD niet is opgenomen aan welke standaards er moet worden voldaan, en op welke aspecten getest moet worden en door wie, bestaat het risico dat niet aan die standaards wordt voldaan, of bepaalde aspecten niet worden getest en daardoor fouten niet gevonden worden. Dit leidt na oplevering tot incidenten.
- De planning wordt onbetrouwbaar. Als het scrumteam tijdens de sprint of tijdens de sprint review ‘verrast’ wordt door ‘nieuwe’ kwaliteitseisen, zal de sprintplanning niet gehaald worden. Als het scrumteam ook zelf de productie-incidenten moet oplossen, zal het vorige punt (meer incidenten) ook impact hebben op de onbetrouwbaarheid van de planning.
- Stakeholders verliezen het vertrouwen in het team. Als tijdens de sprintreview vragen worden gesteld over de niet-functionele aspecten, zoals documentatie en tests, en het antwoord is niet bevredigend, dan kan het vertrouwen van de stakeholders in het scrumteam afnemen. Dat geldt ook als na een oplevering blijkt dat er nog allerlei fouten in zitten, of als keer op keer de toegezegde user stories niet helemaal afgerond blijken te zijn en de planning dus niet gehaald wordt. Het afnemen van het vertrouwen zal de samenwerking niet ten goede komen.
- De scrumteamleden worden ontevreden. De bovenstaande punten komen ook het plezier in het werken in het scrumteam niet ten goede.
Een heldere DoD opstellen
Ben je overtuigd van het belang van een goede Definition of Done? Lees dan het artikel met adviezen over het opstellen van een heldere DoD. Kun je er wel wat hulp bij gebruiken? Neem dan contact op met Accedis via info@accedis.nl of bel 023-5627555.
- Accedis levert als detacheringsbureau diensten op het gebied van informatievoorziening. Deze blog over DoD is opgesteld op basis van een interview met Paul Berg. Paul is projectmanager bij Accedis en heeft jarenlange ervaring met agile werken -