Tips om een heldere Definition of Done op te stellen
In theorie zou ieder scrumteam met een heldere Definition of Done (DoD) moeten werken: een checklist met niet-functionele kwaliteitseisen waar elke user story aan moet voldoen om ‘af’ te zijn. In de praktijk blijkt dat deze DoD vaak niet helder is of geheel niet is vastgelegd. In het artikel ‘Definition of Done, nut en noodzaak’ lees je welke risico’s dat met zich meebrengt en welke voordelen er zijn als er wél een goede DoD is opgesteld. Hoe je dat vervolgens precies doet, lees je hieronder.
Wat is de Definition of Done?
De Definition of Done (DoD) is een checklist met niet-functionele kwaliteitseisen waar elke user story aan moet voldoen. Dit in tegenstelling tot de functionele acceptatiecriteria die bij de user story zelf zijn opgenomen. De DoD gaat om aspecten als documentatie en tests. Het opstellen van een duidelijke DoD heeft veel voordelen.
Maar hoe stel je een goede DoD op?
Betrek de juiste mensen bij het opstellen van de DoD
Het scrumteam als geheel is verantwoordelijk voor het definiëren van de DoD. Maar zij doen dat niet alleen. De kwaliteit van de user stories moet immers aansluiten op de verwachting of eisen van de stakeholders. Wie die stakeholders zijn hangt af van de organisatie en van de positie van het scrumteam binnen de organisatie. Bij een DevOps team is het scrumteam niet alleen verantwoordelijk voor de ontwikkeling van nieuwe software (Development), maar ook voor het beheer (Operations). Daar zullen de eisen vanuit beheer dus door het scrumteam zelf worden opgeleverd. Als het beheer buiten het scrumteam plaatsvindt, komen de eisen van beheer dus van buiten het team. Naast beheer zijn ook de eindgebruikers belangrijke stakeholders, bijvoorbeeld ten aanzien van eenduidige werking of hun inbreng bij de acceptatie. Ook security en architecten hebben vaak verwachtingen en eisen ten aanzien van de kwaliteit. Ook het team zelf kan eisen inbrengen, bijvoorbeeld ten aanzien van de functionele test of documentatie.
Stel de DoD tijdig op
De DoD stel je op vóór de eerste sprint of tijdens de sprintplanning van de eerste sprint. De eisen zullen immers vaak tot taken leiden die in de planning moeten worden vastgesteld, bijvoorbeeld voor het opstellen van documentatie.
Zoals gezegd geldt de DoD voor alle user stories, en ook niet voor één sprint, maar voor alle sprints. Dat wil echter niet zeggen dat hij nooit wordt aangepast. Tijdens de retrospective kan het team vaststellen dat de DoD aangepast moet worden om aan de verwachtingen van de stakeholders te voldoen.
Denk goed na over de inhoud
In de traditionele projectomgeving levert beheer vaak een lijst op met niet-functionele acceptatiecriteria waar het projectresultaat aan moet voldoen. Deze lijst is een prima basis voor de DoD.
Daarbij valt te denken aan het onderstaande. Deze lijst is niet uitputtend.
- Systeemdocumentatie: conform de agile uitgangspunten gaat mondelinge afstemming boven documentatie, maar dat wil niet zeggen dat documentatie niet belangrijk is. De software zal immers ook beheerd moeten kunnen worden en in de toekomst willen de gebruikers mogelijk aanvulling op of aanpassingen van de functionaliteit. Een minimale set aan documentatie is daarom van belang. Wat die minimale set is, komt in de DoD te staan. Deze moet bij oplevering van een user story zijn bijgewerkt. Ook moet in de DoD staan of iemand deze documentatie nog moet reviewen of goedkeuren.
- Belscript en known errors: mogelijk maakt de servicedesk van de organisatie gebruik van een belscript als een gebruiker belt over een applicatie. Dan moet deze mogelijk worden bijgewerkt als de functionaliteit wordt aangepast of uitgebreid. Het kan ook zijn dat er na de test nog open bevindingen zijn, die geaccepteerd zijn maar wel bekend moeten zijn bij de servicedesk (known errors).
- Gebruikersdocumentatie: wellicht kent de applicatie een helpfunctie of een gebruikershandleiding die bijgewerkt moet worden.
- Tests: in de DoD moet staan welke tests er uitgevoerd moeten worden, wie deze moet uitvoeren, in welke omgeving, met welke diepgang er getest wordt, hoe deze gedocumenteerd wordt en wat de acceptatiecriteria zijn om de test af te sluiten. Een soort generiek mastertestplan dus. Sommige tests zijn wellicht niet voor alle userstories relevant of kunnen op basis van een kosten/risico afweging worden overslagen, zoals een performancetest of penetratietest (hacktest). In de DoD leg je vast in welke gevallen zo’n test moet worden uitgevoerd.
- Opleverscript/release notes: als het team het resultaat niet zelf implementeert in productie, maar oplevert aan een aparte beheerorganisatie, zullen die wellicht eisen stellen aan de wijze van oplevering en de beschikbaarheid van release notes.
- Standaards: in de DoD ligt vast aan welke security- of architectuurstandaards de applicatie moet voldoen. Denk daarbij aan encryptie van bepaalde financiële gegevens, of aan browserversies die ondersteund moeten worden.
De kwaliteitseisen in de DoD zijn voor alle user stories geldig, maar hoeven niet voor alle user stories relevant te zijn. Zo kan in de DoD best zijn opgenomen dat het datamodel moet worden bijgewerkt, maar als de user story niet leidt tot het wijziging van dat datamodel, zal er toch geen nieuwe versie van dat datamodel worden opgeleverd. En voor een user story die niet voldoet aan de afgesproken criteria om een performancetest uit te voeren, zal geen performancetest worden uitgevoerd. De DoD zorgt er voor dat deze keuzes bewust gemaakt worden.
Zoals al eerder aangeven is een van de uitgangspunten van agile werken dat onderlinge communicatie belangrijker is dan documentatie. Dat betekent dat het doel niet zal moeten zijn om de DoD tot in alle details te beschrijven, maar dat de diepgang beperkt kan blijven tot wat nodig is voor het scrumteam en haar stakeholders. Het kan altijd nog verder uitgewerkt worden als dat nodig mocht blijken.
Wat staat er niet in een DoD?
In een DoD staat geen eis ten aanzien van de inhoud van de user story zelf. De controle of een user story niet in strijd is met privacywetgeving kan heel legitiem zijn, maar moet uitgevoerd worden voordat de user story wordt opgepakt in een sprint. Als de user story daar niet aan voldoet mag hij niet worden opgepakt. Als de controle zou worden uitgevoerd in het kader van de DoD, is dat te laat.
Ook niet-functionele eisen die voor maar één specifieke user story gelden, of waarvan je op van algemene criteria niet kan bepalen of die relevant zijn voor een specifieke user story, zouden niet in de DoD moeten staan, maar als acceptatiecriteria bij de betreffende user story moeten worden opgenomen. Bijvoorbeeld als de business bij een user story aanvullende print-screentjes wil ten behoeve van een training.
Als er een nieuwe niet-functionele eis wordt toegevoegd waarbij er eerst een inhaalslag moet plaatsvinden, maakt die inhaalslag geen onderdeel uit van de DoD. Daarvoor moet een aparte user story worden aangemaakt. Dus als besloten wordt het lettertype op het scherm te wijzigen, dan kan het nieuwe lettertype wel als nieuwe standaard in de DoD worden opgenomen, maar die geldt alleen voor schermen die in nieuwe user stories worden opgeleverd. Voor het omzetten van de alle bestaande schermen is een aparte user story nodig.
Hulp welkom?
Wil je hulp bij het vaststellen van je Definition of Done? Of heb je regelmatig behoefte aan een interim Product Owner, Scrum Master, business analist of teamlid? Neem dan contact op met Accedis via info@accedis.nl of bel 023-5627555.