“Ik dacht dat het af was! Nu moet ik nóg €20.000 investeren om het netjes te maken?”
Wie bovenstaande uitspraak herkent, kan misschien wel een lesje ‘verwachtingsmanagement’ gebruiken. Blijkbaar was het voor de opdrachtgever niet helemaal duidelijk wat hij als eindproduct zou krijgen. Bovendien valt het eindproduct tegen, want hij moet flink extra investeren. De Definition of Done (D.o.D.) kan helpen om de transparantie in een ontwikkelproces te bevorderen. Hoe dat werkt en hoe je een D.o.D. opstelt, vertel ik in deze blog.
Waarom een Definition of Done bepalen?
In beginsel is de D.o.D. bedoeld om de transparantie van het ontwikkelproces te bevorderen. Dit helpt niet alleen de verwachtingen van de stakeholders te managen, maar heeft ook een functie voor de betrokken teams en product owners. Want niets is verwarrender dan een situatie waarin de sprints steeds tot een ander resultaat leiden dan aanvankelijk verwacht werd. Daarnaast werkt een strak ingerichte en gehanteerde D.o.D. gewoon prettig. Het team houdt zijn focus doordat het de taak eerst afmaakt voordat er aan iets nieuws begonnen wordt. En dat vindt ons brein erg prettig, we zijn namelijk niet zo’n goede multitaskers.
Een voorbeeld van de D.o.D.
Hoe ziet zo’n Definition of Done er dan in de praktijk uit? Ik geef wat voorbeeld van wat er in een D.o.D. kan staan:
- Aan de acceptatiecriteria van de story is voldaan
- De demo is voorbereid
- Code review is gedaan
- Test is volbracht en toegevoegd aan automatisch testscript
- Deployment scripts staan klaar
- Documentatie is bijgewerkt
Zoals je aan deze voorbeelden kunt zien, overstijgt de D.o.D. alle stories. Het bevat eigenlijk de acceptatiecriteria die gelden voor alles wat het team oplevert.
Waar stopt de Definition of Done?
De definitie geldt dus voor alle stories, maar is wel eindig. In het ideale geval loopt de D.o.D. helemaal totdat de software geleverd is. Of dat mogelijk is, verschilt per situatie. Hier spelen bijvoorbeeld afhankelijkheden in de organisatie in mee, of de complexiteit van de omgeving waarin de software gebruikt zal worden. Het ontwikkelproces is in ieder geval pas echt klaar als het opgeleverde expliciet waarde toevoegt en iets is waar je feedback op kunt krijgen.
Hoe maak je een D.o.D.?
Een Definition of Done is niet in één keer af. Verwacht dat je wat tijd moet investeren en dat de invulling ervan tot discussie zal leiden. Onze aanpak is als volgt: we verzamelen het team en bekijken wat er allemaal gedaan moet worden voor één wens. Dit levert vaak discussie en sommige teamleden zullen wat beren op de weg zien. Dat is niet erg, want het vormt een goed moment om eens de manier van (samen)werken te bespreken. Neem hier de tijd voor, maar zorg wel dat de discussie zich op hoofdlijnen blijft richten. Het doel van de sessie is om een initiële definitie te maken waarmee je gaat werken in de eerste sprint. In de volgende retrospectives controleer je of de definitie nog klopt en pas je ‘m zo nodig aan.
Zie jij nog beren op de weg?
Met een duidelijke Definition of Done die alle stories overstijgt, help je de stakeholders én je eigen team. De opdrachtgever weet welk resultaat hij kan verwachten. Het team behoudt zijn focus op de taken die daadwerkelijk tot de wens behoren. Verwachtingmanagement 2.0! Heb jij ervaring met het opstellen van een D.o.D. of werk je er regelmatig mee? Welke beren stonden er in jouw geval op de weg naar een complete definitie? Deel je ervaringen in een reactie! Ik ben benieuwd.
