Voltaire deed de beroemde uitspraak dat perfectie de vijand is van goed. Moderne softwareontwikkelteams begrijpen dat ze producten moeten leveren en dat innovatie een iteratief proces is. 

Weten wanneer een product of project 'done' of 'klaar' is, helpt agile-teams te voorkomen dat ze in een eindeloze reeks iteraties belanden die een project eerder kwaad dan goed doen. Een gebrek aan overeenstemming over wat 'klaar' exact betekent, kan leiden tot verlammend perfectionisme of zelfs apathie.  

Omdat een DoD in een vroeg stadium van een project moet worden vastgesteld, is het essentieel dat dit wordt behandeld in de eerste planning en brainstorming van een project. In dit artikel kijken we hoe projectmanagers en agile-teams met behulp van een DoD flexibel, productief en gefocust op de gebruikerservaring blijven, en hoe je een DoD opstelt. 

Waarom een DoD gebruiken 

Ervaring is de beste leermeester en de gebruikerservaring is de beste manier om te zien of je product voldoet aan de behoeften van de gebruiker. Maar om dat inzicht te kunnen verkrijgen, heb je natuurlijk een geïntroduceerd product nodig. 

Door een Definition of Done te bepalen en in je workflowproces op te nemen, kom je sneller tot dat geïntroduceerde product, of ten minste tot een minimaal levensvatbaar product. Vervolgens kun je de feedback krijgen die je nodig hebt om betere producten te maken, je planning te verbeteren en toekomstige projecten te visualiseren en te plannen. Laten we elk van deze voordelen eens nader bekijken.

1. Nuttige feedback voor verbetering krijgen

Een DoD weerspiegelt de noodzakelijke stappen om een incrementele sprint te realiseren. Voor scrum- en agile-teams biedt deze benchmark een gelegenheid om te testen, te itereren, te leren en het resultaat van de volgende sprint te verbeteren. Elke stap van de DoD-checklist biedt een kans om feedback te ontvangen terwijl het releaseplan op schema blijft. 

2. Planning verbeteren

Als een project nooit 'klaar' is, zijn er waarschijnlijk veel tussentijdse stappen die toekomstige sprints en workflows onduidelijk en onoverzichtelijk kunnen maken. Eindeloze productsprints resulteren vaak in onnodig ingewikkelde problemen, en hoewel kwaliteit en functionaliteit altijd het doel zijn, is het erg zinvol om een minimaal levensvatbaar product te introduceren en te leren van gebruikersinteracties. 

Definition of Done helpt scrum- en agile-teams om productleveringen op te splitsen in definieerbare stappen, waardoor toekomstige sprints beter gepland kunnen worden. Met behulp van DoD kunnen ontwikkelteams leveren, testen, leren, itereren en herhalen met een toekomstgerichte visie en vooruitgang boeken. 

3. De status van projecten in de tijd visualiseren

Een Definition of Done helpt je niet alleen om je planning te verbeteren, maar ook om de voortgang van een project te visualiseren. Daardoor heb je altijd een duidelijk beeld van wat er gedaan is, wat er nu gedaan moet worden en welke kant het op gaat met productontwikkeling. Dergelijke transparantie helpt ook om alle neuzen in de organisatie dezelfde kant op te krijgen. Als richtinggevende gesprekken en productontwikkelingswerk in silo's plaatsvinden, lopen strategische paden al snel uiteen. 

Hoe ziet DoD er precies uit? Het kan op veel manieren toegepast worden, maar individuele controlepunten worden meestal gedocumenteerd in een product roadmap of een scrum board waarop duidelijk te zien is hoe een productsprint ervoor staat. 

Na verloop van tijd draagt een Definition of Done bij aan de snelheid van een team door dubbel werk te voorkomen en te zorgen dat de leverbare staat van het product of de app-omgeving voldoet aan de eisen van user story's en marktverwachtingen. 

4. Weerspiegelt de kwaliteit van een agile-project

Agile-workflowmethoden zijn inherent flexibel maar ook resultaatgericht. Ervaren scrum- en agile-teams zijn gebaseerd op deze flexibele manier van werken, maar zijn het ook eens over gezamenlijke doelstellingen en zetten zich in om het best mogelijke product zo snel mogelijk te leveren. Definition of Done ondersteunt en weerspiegelt die flexibiliteit. 

Je Definition of Done bepalen

We hebben de risico's van perfectionisme en apathie aangestipt. Beide kunnen het gevolg zijn van een niet correct gedefinieerde DoD en beide hebben tot gevolg dat het product niet geïntroduceerd kan worden. Verschillende teams en stakeholders kunnen verschillende ideeën hebben over hoe 'done' eruitziet, maar het is belangrijk om samen te werken en compromissen te sluiten om consensus te bereiken over acceptatiecriteria voor elke user story, functie of issue en elk teamlid verantwoordelijk te houden voor die normen. Die vereisten moeten duidelijk, uitvoerbaar en altijd toegankelijk zijn.

Bepaal als team je definitie van 'done'

Een Definition of Done moet vastgesteld worden via een functieoverschrijdende samenwerking tussen productteams, projectmanagers, kwaliteitscontrole en relevante stakeholders. Je DoD hangt af van je huidige gebruikers- en bedrijfsprioriteiten, maar betekent over het algemeen dat de ontwikkelde code voldoet aan de doelstellingen van de user story, functie, release of issue en geen eerdere sprint van productontwikkeling verstoort. 

Definition of Done voorbeeld

Op een tactischer, gedetailleerd niveau kan een DoD-checklist er als volgt uitzien: 

• Code is geschreven
• Code is gedocumenteerd
• Code is gecontroleerd
• Code of build is geïmplementeerd in een testomgeving 
• Code doorstaat tests 

Naast meer traditionele visualisatie- en agile-projectmanagementtools zoals product roadmaps en scrum boards kunnen visuele samenwerkingstools zoals Lucidspark ook zorgen voor transparantie rond DoD-vereisten voor niet-technische teams, voor toegang tot die vereisten voor alle betrokkenen en voor overeenstemming over wat er nodig is om de functie te implementeren en wat daarna komt. 

Stel een checklist en specifieke vereisten op om te voldoen aan de DoD (acceptatiecriteria)

Simpel gezegd zijn acceptatiecriteria de benchmarks die nodig zijn om aan je DoD te voldoen. Als je eenmaal een DoD hebt bepaald, moet je een checklist opstellen met regels die rekening houden met het grotere geheel en de context van de huidige sprint en die van toepassing zijn op elke taak binnen die sprint, of dat nu een geheel nieuwe app of een eenvoudige bugfix is. Het allerbelangrijkste is consistentie. 

Hier is een eenvoudige 'done'-checklist met acceptatiecriteria. Opmerking: deze criteria kunnen na verloop van tijd veranderen als je DoD en productvereisten en -prioriteiten veranderen. 

• Test unit geslaagd
• Code gecontroleerd
• Voldaan aan acceptatiecriteria voor elke issue
• Functionele tests geslaagd
• Voldaan aan niet-functionele vereisten
• De product owner accepteert de user story

Als al deze items afgevinkt zijn, kun je een sprint als 'done' beschouwen en vervolgens je ervaringen observeren, testen en toepassen om nieuwe productfuncties te bedenken, bugs op te lossen, huidige functies te itereren en te optimaliseren en je volgende sprint te plannen. En weet je wat het mooiste is van een Definition of Done? Je team gaat altijd vooruit en leert voortdurend. 

Verbind verantwoordelijkheid aan actiepunten

Overeenstemming over acceptatiecriteria is essentieel om elk teamlid verantwoordelijk te houden voor elke stap. Tijdens het plannen van je sprint zijn individuele teamleden verantwoordelijk voor verschillende stappen. Zorg dat je acceptatiecriteria en checklists te zien zijn op de plek waar het werk gedaan wordt, zodat verantwoordelijkheden in elke fase van de ontwikkelingscyclus zichtbaar en duidelijk zijn. 

Stem DoD af op organisatorische eisen of contractdoelstellingen

Om verspilling van werk en sprints te voorkomen, is het belangrijk af en toe je prioriteiten en je DoD af te zetten tegen de bredere doelen van je organisatie. Zo zorg je voor afstemming en voorkom je strategische blinde vlekken. Want een geslaagde productlevering is slechts zo waardevol als de doelen die ermee bereikt worden. Nauwe samenwerking en afstemming met de belangrijkste stakeholders en product owners zorgt dat elke productsprint het bedrijf als geheel ten goede komt. 

Voor veel kwaliteitsgerichte productontwikkelingsteams kan het verleidelijk zijn om bij elke sprint en elke versie van een app te streven naar perfectie. Teams die DoD toepassen, kunnen flexibel te werk gaan, sneller meer over hun gebruikers leren en uiteindelijk betere producten maken.