7.5 minuten leestijd

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 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 acceptatiecriteria 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 acceptatiecriteria. 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 acceptatiecriteria 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)
Dit is hoe jij de definition of done voor een nieuw of lopend project kunt 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 wij 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:

  • Contenttypes 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 acceptatiecriteria?

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 acceptatiecriteria?

  • Goede acceptatiecriteria 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 acceptatiecriteria 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 acceptatiecriteria bij een inlog functionaliteit op een website.

  • Ik kan inloggen met een emailadres
  • 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 acceptatiecriteria?

Het bepalen van acceptatiecriteria 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 acceptatiecriteria.

  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 acceptatiecriteria
  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 acceptatiecriteria vast aan de hand van bovenstaande kerkenningspunten. (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 acceptatiecriteria te overlopen. Onze ervaring is dat naarmate het team en het product groeit, de acceptatiecriteria steeds beter worden.

En nu?

Al het begin is lastig. Zowel bij de definition of done als bij acceptatiecriteria 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 acceptatiecriteria, dat je kwaliteit dan altijd zal gaan stijgen. Met blijere klanten tot gevolg.

Heb je direct een ervaren product owner nodig die zelfstandig jouw project tot een succes brengt binnen de gestelde deadline en budget? Beschrijf jouw situatie in een korte mail naar jochem@productowner.nl of stuur een appje naar 06 16746577. Wij leveren met de eerste kop koffie gegarandeerd meer rust en inzicht.

Direct een product owner inhuren? Ook hier kunnen we je mee helpen.

Vragen of opmerkingen, stuur ons een bericht.

    Deel dit bericht

    Wil je meer weten?

      Ons team zal contact met je opnemen.