Skip to main content
Key Takeaways

Consistente kwaliteit: Een gedeelde definitie van gereed voorkomt verwarring en verbetert de kwaliteit van het werk binnen het team.

Betere prognoses: Een duidelijke definitie helpt bij het nauwkeurig voorspellen van de snelheid en het beter plannen van projecten.

Veelvoorkomende valkuilen: Voorkom dat je de definitie te gedetailleerd maakt of nalaat deze af te dwingen, want beide kunnen tot problemen leiden.

Praktische stappen: Het artikel beschrijft concrete stappen om een succesvolle definitie van gereed voor agile teams te creëren.

De definitie van gereed (DoD) is de gedeelde standaard die bepaalt wanneer werk echt voltooid is. Deze helpt kwaliteitslacunes, herstelwerk en verrassingen helemaal aan het einde van de sprint te voorkomen. Ik heb ontwikkelingsteams het vertrouwen zien verliezen, deadlines zien missen en onnodige conflicten zien veroorzaken omdat iedereen een andere interpretatie van "gereed" had. 

In deze handleiding leer je hoe je een definitie van gereed opstelt die je agile team op één lijn brengt, de voorspelbaarheid verbetert en de kwaliteit versterkt, inclusief praktische voorbeelden, sjablonen en veelgemaakte fouten die je moet vermijden. 

Wat is de definitie van gereed?

De definitie van gereed is een formele, gedeelde reeks criteria waaraan een item uit de productbacklog of een increment moet voldoen voordat het team het als voltooid en potentieel klaar voor release beschouwt. Zie het als het kwaliteitscontract dat je team zich ertoe verbindt voor elk stuk werk na te leven, ongeacht de omvang of complexiteit ervan.

Create a Free Account to Read More

Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time.

Dit zijn de belangrijkste kenmerken van een effectieve definitie van gereed:

  • Transparant: Iedereen in het team en belangrijke belanghebbenden kunnen deze op elk moment bekijken, lezen en raadplegen.
  • Meetbaar: Elk criterium is binair. Het werk voldoet er wel of niet aan, maar over de drempelwaarden die je voor kwantitatieve criteria kiest, moet je goed nadenken. Een doelstelling van 80% codedekking is binair in de handhaving, maar de keuze voor 80% in plaats van 70% of 90% is een afweging die je bewust moet maken
  • Universeel begrepen: Elk lid van het Scrumteam moet elk onderdeel op dezelfde manier kunnen interpreteren.
  • Consistent toegepast: Dezelfde checklist moet op elk resultaat en elk item in de productbacklog worden toegepast. 
  • Haalbaar binnen een sprint: De criteria moeten realistisch genoeg zijn zodat het team eraan kan voldoen tijdens één sprint of iteratie.

Bij softwareontwikkelingsprojecten zijn ontwikkelaars doorgaans eigenaar van de definitie van gereed, omdat zij verantwoordelijk zijn voor de naleving ervan. Dat gezegd hebbende, moeten de product owner en Scrum Master bijdragen.

Als je organisatie eigen normen voor de definitie van gereed heeft, moet elk Scrumteam deze minimaal als basis volgen. Teams kunnen altijd strengere criteria toevoegen, maar ze mogen niet onder de organisatorische ondergrens komen.

Waarom de definitie van gereed belangrijk is

Een duidelijke definitie van gereed is belangrijk omdat deze voorkomt dat gedeeltelijk voltooid werk door de mazen van het net glipt en een gedeelde kwaliteitsstandaard biedt.

Dit zijn enkele aanvullende redenen waarom een gedeelde definitie van gereed belangrijk is:

  • Fungeert als ingebouwde kwaliteitscontrole: Elk item moet aan dezelfde norm voldoen voordat het voltooid kan zijn. Hierdoor voorkom je dat halfaf werk in je productincrement terechtkomt en zich opstapelt als technische schuld.
  • Elimineert onduidelijkheid: Wanneer het team één definitie deelt, kom je niet terecht in situaties waarin tegenstrijdige definities de snelheid of kwaliteit van het werk beïnvloeden. Een gedeelde definitie van gereed betekent minder conflicten, minder verrassingen en soepelere demo's.
  • Verbetert prognoses: Wanneer gereed in elke sprint hetzelfde betekent, kun je de snelheid met vertrouwen voorspellen en releases plannen zonder schattingen op te hogen om rekening te houden met herstelwerk.
  • Bouwt vertrouwen bij belanghebbenden op: Wanneer product owners, het management en externe belanghebbenden kunnen zien dat je team een duidelijke kwaliteitsstandaard handhaaft, vertrouwen ze op je resultaten. 
  • Voorkomt integratiechaos: Als je werkt op een manier waarbij het team zijn werk moet integreren in een gedeeld increment, vormt een gedeeld begrip van de definitie van gereed de basis voor consistente increments die klaar zijn voor release. 

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time.

Een definitie van gereed opstellen

Dit zijn de belangrijkste stappen in het proces voor het opstellen van een definitie van gereed.

  1. Controleer je huidige werkproces: Breng elke stap in kaart die je werk al doorloopt voordat het in productie komt. Praat met ontwikkelaars, testers, ontwerpers en iedereen die verder bij het werk betrokken is. Je ontdekt informele kwaliteitsstappen die geformaliseerd moeten worden.
  2. Identificeer niet-onderhandelbare kwaliteitscriteria: Bepaal welke activiteiten voor elk werkstuk moeten worden uitgevoerd. Dit omvat doorgaans codebeoordeling, geautomatiseerd testen, het bijwerken van documentatie en beveiligingsscans. Wees eerlijk over wat je momenteel overslaat.
  3. Stel de checklist gezamenlijk op: Breng het hele team samen en werk de checklist uit met behulp van een whiteboard of gedeeld document waarin iedereen in realtime items kan toevoegen, ter discussie kan stellen en verfijnen. Een definitie van gereed die via consensus is aangenomen, houdt onder druk veel beter stand dan een definitie die ondanks bezwaren is doorgedrukt.
  4. Toets aan organisatiestandaarden: Vergelijk je concept met eventuele organisatiebrede kwaliteitsrichtlijnen, wettelijke vereisten of branchenormen waaraan je product moet voldoen. Als je organisatie al een basisdefinitie van gereed heeft, begin daar dan mee en bouw daarop voort.
  5. Maak het zichtbaar: Hang de definitie op de plek waar je team elke dag werkt. Dat kan een poster aan de muur zijn, een vastgezet bericht in Slack of een paneel in je projectmanagementtool.
  6. Houd je eraan: Een definitie van gereed die wordt genegeerd wanneer deadlines naderen, is erger dan helemaal geen definitie, omdat deze een vals gevoel van kwaliteit creëert. 

Voorbeelden van een definitie van gereed

Hier zijn enkele voorbeelden van definities van gereed voor verschillende soorten projecten:

Definitie van gereed voor softwareontwikkelingsprojecten

Softwareprojecten hebben te maken met een groot aantal kwaliteitsrisico's: bugs, beveiligingskwetsbaarheden, prestatieverminderingen en integratiefouten. De definitie van gereed voor een softwareteam moet het volledige traject van code tot een vrijgaveklare staat omvatten.

Dit kan er als volgt uitzien:

  • Alle code is geschreven en door ten minste één andere ontwikkelaar beoordeeld
  • Unittests slagen met de overeengekomen dekkingsdrempel
  • Integratietests slagen in de CI/CD-pijplijn
  • Er zijn geen openstaande bugs met een kritieke of hoge ernst
  • De technische documentatie is bijgewerkt om de wijzigingen weer te geven
  • De code is samengevoegd met de hoofdbranch
  • De producteigenaar heeft het werk beoordeeld en geaccepteerd
  • Er is voldaan aan de prestatiebenchmarks volgens de overeengekomen drempelwaarden

Definitie van gereed voor marketingprojecten 

Marketingwerk heeft vaak aspecten op het gebied van naleving, merkidentiteit en metingen die verschillen van software. 

Zo kan de definitie van gereed voor een marketingproject eruitzien:

  • De content is door het juridische team beoordeeld en goedgekeurd
  • De SEO-checklist is voltooid, inclusief metabeschrijvingen, alt-tekst en interne links
  • Alle middelen zijn naar het CMS geüpload en correct opgemaakt
  • Analytische tracking is geconfigureerd en geverifieerd in de testomgeving
  • De definitieve tekst is door een tweede teamlid nagelezen
  • De checklist voor de lancering van de campagne is door de teamleider goedgekeurd

Definitie van gereed voor ontwerpprojecten 

Ontwerpteams hebben een definitie van gereed nodig om de kloof tussen creatieve intentie en technische overdracht te overbruggen. Zonder zo'n definitie komen ontwerpen onvolledig aan bij de ontwikkeling, met ontbrekende specificaties, niet-gevalideerd responsief gedrag of hiaten op het gebied van toegankelijkheid die te laat worden ontdekt.

Hier is een voorbeeld van een definitie van gereed voor een ontwerpproject:

  • Het ontwerp is getoetst aan toegankelijkheidsstandaarden volgens WCAG 2.2
  • Het overdrachtsbestand is voorbereid in de overeengekomen tool, met alle specificaties, middelen en annotaties
  • De goedkeuring van belanghebbenden is ontvangen en gedocumenteerd
  • De componenten van het ontwerpsysteem zijn bijgewerkt als er nieuwe patronen zijn geïntroduceerd
  • Het responsieve gedrag is gevalideerd voor de overeengekomen breekpunten

Definitie van gereed versus acceptatiecriteria

De definitie van gereed is de kwaliteitsstandaard op teamniveau, terwijl acceptatiecriteria functionele vereisten op functieniveau zijn.

Beschouw de definitie van gereed als de basisnorm die universeel van toepassing is, en acceptatiecriteria als uniek voor elke sprintbacklog of elk productbacklogitem. Een productbacklogitem is gereed wanneer het zowel aan de acceptatiecriteria als aan de definitie van gereed van het team voldoet.

AspectDefinitie van gereedAcceptatiecriteria
ReikwijdteVan toepassing op elk productbacklogitem en elke incrementSpecifiek voor een individueel user story of productbacklogitem
EigenaarschapIn handen van de ontwikkelaars, met inbreng van het volledige ScrumteamGeschreven door of samen met de product owner
SpecificiteitAlgemene kwaliteitsnormen voor al het werkGedetailleerde functionele vereisten voor één stuk werk
Frequentie van wijzigingenWordt zelden gewijzigd; bijgewerkt tijdens sprintretrospectivesWijzigt met elk nieuw user story
HandhavingsmomentGecontroleerd voordat een item als voltooid wordt gemarkeerdGevalideerd tijdens de beoordeling van het user story of acceptatietesten

Veelvoorkomende valkuilen en fouten

Hier zijn enkele veelvoorkomende fouten die je moet vermijden bij het opstellen van definities van gereed:

  • Items overslaan om sneller vooruitgang te boeken: Teams laten onder tijdsdruk vaak criteria zoals een beveiligingsbeoordeling, toegankelijkheidstests of documentatie vallen. Hierdoor ontstaat verborgen technische schuld die later aan het licht komt in de vorm van bugs, herstelwerk of complianceproblemen.
  • De checklist te gedetailleerd maken: Een overdreven gedetailleerde definitie van gereed wordt een bureaucratische last. Als je checklist 30 items bevat en ontwikkelaars meer tijd besteden aan het afvinken van vakjes dan aan het bouwen van software, ben je te ver gegaan. Wees specifiek genoeg om betekenisvol te zijn, maar algemeen genoeg om praktisch te blijven.
  • De definitie van gereed per user story wijzigen: Het hele doel van de definitie van gereed is consistentie. Functiespecifieke voorwaarden horen thuis in de acceptatiecriteria (zoals given-when-then-acceptatiecriteria), niet in de definitie van gereed.
  • De definitie nooit opnieuw bekijken: Een definitie van gereed moet zich ontwikkelen naarmate je werkwijzen volwassener worden, je tooling verandert of je product groeit. Ik raad aan om deze tijdens retrospectives minstens één keer per kwartaal te beoordelen en aan te passen wanneer het team hiaten of wrijving constateert.
  • De definitie niet handhaven: Een definitie die terzijde wordt geschoven wanneer iemand belangrijk daarom vraagt, is nutteloos. Het is de taak van de Scrum master om de definitie te beschermen, zelfs wanneer een stakeholder iets wil uitbrengen dat niet aan de norm voldoet. Als criteria routinematig worden genegeerd, verliest het team vertrouwen in de norm en neemt het deze niet langer serieus.
  • "Gereed" verwarren met geïmplementeerd: De definitie van gereed bepaalt of een increment kan worden vrijgegeven, niet of het al is vrijgegeven. Een productbacklogitem kan gereed zijn zonder geïmplementeerd te zijn. Voeg "geïmplementeerd in productie" niet toe aan je definitie van gereed, tenzij je team echt het volledige releaseproces van begin tot eind beheert.
  • Verzuimen ernaar te verwijzen: Veel teams hebben technisch gezien een definitie van gereed, maar als niemand ernaar heeft gekeken sinds deze zes maanden geleden is opgesteld, functioneert deze niet als kwaliteitsnorm.

Wat nu?

Werk verder aan je agile processen en werkwijzen met praktische tools, sjablonen en inzichten van experts via een gratis DPM-lidmaatschap, en versterk de systemen die teams helpen om consistent kwaliteitswerk te leveren.