In iedere organisatie wordt scrum en agile net iets anders gebruikt. En dat is wat ons betreft helemaal oké. Toch is het naar onze bescheiden mening goed om als product owner even stil te staan bij enkele termen die vaak door elkaar heen worden gebruikt: ‘definition of done’, ‘definition of ready’ en ‘acceptatiecriteria’. In deze korte blog leggen wij je het verschil uit.

De definition of ready is een vaste lijst met punten waar aan voldaan moet worden om iets van de backlog (de grote to-do lijst) te verplaatsen naar de sprint (het werk dat we de komende periode gaan doen). De definition of done is een vaste lijst met punten waar iedere user story aan moet voldoen om als done te worden afgestreept. De acceptatie criteria zijn voor elke specifieke user story anders en laten zien wanneer de story bruikbaar is. Wat ze allemaal gemeenschappelijk hebben: ze zorgen voor transparantie en heldere verwachtingen. En dus minder rework, minder doorlooptijd en een hogere output. Dat resulteert weer in een toffer product en dus blijere gebruikers. Het is dus goed om bij de sprint review stil te staan bij de toepasbaarheid en volledigheid van deze lijstjes.

De definition of done wordt bepaald door het ontwikkelteam. Daarentegen is de product owner verantwoordelijk voor de acceptatie criteria. Het behoeft hopelijk geen betoog dat in beide gevallen harmonie en samenspraak beter werkt dan afdwingen. De definition of ready wordt in de meeste gevallen bepaald door het gehele team.

Wat is de definition of done?

De definition of done geeft een duidelijke omschrijving van hoe álle opgeleverde Product Backlog items (user stories) er uit moeten zien voor deze als ‘klaar’ kunnen worden afgestreept. Het is dus een generieke lijst voor iedere story.

Als een team langer samenwerkt aan het product, dan ontstaat er voortschrijdend inzicht. Het is goed om de definition of done elke 2-3 sprints onder de aandacht te brengen tijdens de review.

Voorbeeld van een definition of done:

• Alle taken in de user story zijn afgerond
• Alle acceptatie criteria zijn getest en akkoord bevonden
• Er heeft een review/test plaatsgevonden door een tweede persoon. (developer, tester, product owner of specialist)
• De documentatie is gemaakt, gecheckt en toegevoegd aan de bestaande documentatie
• De feature voldoet aan de wettelijke eisen. (AVG bij veel producten, dit is een heet hangijzer bij bijvoorbeeld hypotheeksoftware)
• De UX/UI is akkoord bevonden. (door UX-er, key user of product owner)

Definition of done implementeren

1. Laat iedereen deze blog lezen of laat een ervaren persoon het de groep uitleggen.
2. Laat iedereen 5-10 minuten naar de Backlog kijken en vragen stellen aan de PO over specifieke stories. Het doel is om inzicht te krijgen in wat er voor werk ligt. Het is niet de bedoeling om alles tot in detail uit te pluizen, dus time cap op 10 minuten is aan te bevelen.
3. Iedereen schrijft voor zichzelf drie post-it’s met belangrijkste punten waaraan al het werk moet voldoen,dat doet ieder vanuit zijn eigen overtuiging/expertise. Er is geen goed of fout.
4. Iedereen krijgt 1 minuut om zijn post-it’s toe te lichten. Hang ze vervolgens allemaal op 1 whiteboard/raam/deur. Meteen ontdubbelen
5. Door middel van Dotvoting met stickers of stippen van een stift kun je bepalen hoe de groep hier naar kijkt. Aantal stickers = teamleden gedeeld door 2. Je mag op jezelf stemmen, op je baas stemmen of die hele leuke collega is een minder goed idee (tenzij het een goed idee is natuurlijk). Als er al een sticker hangt en je vind het een goed idee; vooral doen. Het resulteert namelijk in een Heat map.
6. Probeer een top 3-5 te vinden voor de eerste versie. Let op in het uiteindelijke selecteren heeft het ontwikkelteam het beslisrecht.
7. Spreek met elkaar af om periodiek (elke of om de sprint in de review/retro) te reviewen.

Definition of ready.

De definition of ready definieert de criteria waaraan een specifieke user story moet voldoen voordat hij in aanmerking komt voor opname in een sprint. Voorbeelden van de definition of ready zijn:

• De user story is duidelijk voor iedereen in het ontwikkelteam.
• Er zijn acceptatiecriteria opgesteld.
• De user story kan volgens iedereen goed uitgevoerd worden

Dit lijstje komen we vaker in dit format tegen. Wij raden dan ook aan met dit lijstje te beginnen en steeds bij elke user story na te gaan of het er is. Mocht je als team na verloop van tijd een extra punt voor de op de lijst tegenkomen, dan kan die worden toegevoegd.

Eentje die onze product owners vaak willen toevoegen is dat we zeker willen weten dat de business ook doordrongen is dat deze feature er aan komt en er dus actie moet worden ondernomen. Voorbeelden zijn dan:

• Content types en hoeveelheid zijn bepaald en productie ervan is gestart. (tekst, visual, video, audio)
• De feature is aangekondigd in het operations team
• In team X of organisatie Y zijn resources beschikbaar voor ondersteuning.

Wat zijn acceptatie criteria?

Acceptatie criteria gelden voor één specifieke user story. Het geeft antwoord op de vraag wat er op moet worden geleverd om de nieuwe feature daadwerkelijk te kunnen gaan gebruiken.

Hoe herken je goede acceptatie criteria?

• Goede acceptatie criteria zijn meetbaar; Het is óf goed, óf fout. Dit moet niet tot discussie kunnen leiden.
• Het werkt alleen als ze ook realistisch zijn. Een hele zware database met een laadtijd van 0,00001 seconde terwijl er niet is geïnvesteerd in servercapaciteit is geen realistisch.
• Wat ook heel belangrijk is, is dat acceptatie criteria los staan van elkaar. Het mag niet in elkaar verweven zijn of een domino effect triggeren dat als er één niet is gehaald, dat de rest dan ook automatisch op rood komt te staan.

Hieronder een voorbeeld van de acceptatie criteria bij een inlog functionaliteit op een website.

• Ik kan inloggen met een e-mailadres
• Ik krijg een foutmelding wanneer het mailadres niet bekend is in de database (conform design)
• Ik krijg een melding als de combi ww/mail niet klopt (conform design)
• Ik kan inloggen met Facebook
• Na succesvol inloggen kom ik in hetzelfde venster terug op de pagina waar ik was.

Hoe bepaal je de acceptatie criteria?

Het bepalen van acceptatie criteria is geen exacte wetenschap, maar gelukkig ook niet complex. Aan de hand van het volgende stappenplan kan je bij de eerstvolgende sprint al gaan werken met acceptatie criteria.

1. Bepaal wie de acceptatietest van deze user story gaat doen. Is het een developer, een tester, de product owner, een super user of nog iemand anders? Of is het een gezamenlijke inspanning? De mensen die testen zouden wat ons betreft betrokken moeten worden bij het opstellen van de acceptatie criteria
2. Laat de product owner – voor zover niet duidelijk – uitleggen wat deze story oplost voor de gebruiker. Doe waar nodig Q&A.
3. Stel al pratend en luisterend een aantal punten op die belangrijk zijn voor de gebruiker. In ons voorbeeld hierboven was het email, facebook, foutmelding, landen.
4. Stel per punt één of meerdere acceptatie criteria vast aan de hand van bovenstaande herkenningspunten. (meetbaar, realistisch, losstaand)
5. Doen. zeker in het begin is het lastig en je kan met een onzeker gevoel rond blijven lopen omdat je – ondanks goede voorbereiding – soms de uitkomst niet perfect kan voorstellen. Staar je niet blind op een perfecte lijst tijdens de eerste sprints.
6. Evalueren. Bij een sprint review is het goed om de acceptatie criteria te overlopen. De ervaring van onze product owners is dat naarmate het team en het product groeit, de acceptatie criteria steeds beter worden.

En nu?

In het begin kan dit als product owner lastig zijn. Zowel bij de definition of done als bij acceptatie criteria geldt dat je met het team aan de slag moet gaan en het in de praktijk moet ondervinden. En als je tijdens de reviews aandacht besteed aan de kwaliteit en inzetbaarheid van zowel de definition of done als de acceptatie criteria, dat je kwaliteit dan altijd zal gaan stijgen. Met blijere klanten tot gevolg.

Wij helpen jou graag verder ontwikkelen als product owner, bekijk hier onze trainingen voor product owners. Ben je op zoek naar een product owner die stil kan staan bij jouw definition of done? Klik dan hier voor onze werving & selectie van product owners.