slim
samen
werken

Wat is de Definition of Ready?

De Definition of Ready is de verzameling afspraken die het Scrum Team maakt om te bepalen welke items klaar zijn om door de Developers (voorheen het Development team genoemd) in de Sprint te worden verwerkt. Dit is van belang omdat het doel van het Scrum Team is om zo snel mogelijk de meest waardevolle items op te leveren. Door goede afspraken te maken over de kwaliteit van de User Stories, kunnen de Developers deze User Stories sneller oppakken en sneller opleveren.

definition of ready

Wat betekent de Definition of Ready?

In de Scrumguide wordt niet gesproken over een Definition of Ready. Toch wordt deze in de praktijk door veel Scrum Teams gebruik. In de Scrum Guide wordt slechts gesproken over Product Backlog  Items die klaar zijn om opgepakt te kunnen worden door het team. Hoe je bepaalt wanneer een item klaar is, wordt niet besproken.

Een Definition of Ready kan het Scrum Team helpen om afspraken vast te leggen om te bepalen welke items klaar zijn om door het Development team in de Sprint te worden verwerkt. Dit is van belang omdat het doel van het Scrum Team is om zo snel mogelijk de meest waardevolle items op te leveren. Door goede afspraken te maken over de kwaliteit van de User Stories, kan het Team deze User Stories sneller oppakken en sneller opleveren.

Het Scrum Team legt een Definition of Done vast om te bepalen welke items gedurende een Sprint afgerond zijn. De Definition of Ready is een vergelijkbare set afspraken.

Waarom is het verstandig om een Definition of Ready te gebruiken?

In de praktijk zie je Product Owners vaak worstelen met het opschrijven van Product Backlog Items. Veelal worden deze in de vorm van zogenaamde User Stories opgeschreven.

User Stories volgen dit sjabloon:
Als [Stakeholder] Wil ik [Wens] Zodat ik [Reden voor de wens, oplossing voor het probleem]

Een van de problemen waar Product Owners tegenaan lopen bij het opschrijven van User Stories is het van tevoren goed in schatten of de User Story voldoende informatie bevat om het Team compleet beeld te geven van de wens van de Stakeholder.
Hierbij moet de Product Owner een subtiele balans vinden tussen het geven van voldoende duidelijke informatie over het ‘wat’ zonder te bepalen ‘hoe’ deze wens uitgevoerd moet worden.
Ook is het vaak lastig om de User Story niet te groot te maken. Product Owners en Stakeholders hebben vaak veel en grote wensen. Het Team heeft daarentegen de behoefte aan kleine behapbare stukken werk om tijdens een Sprint op te kunnen leveren. Ook hier is het zaak om de balans in de gaten te houden. De User Story moet enerzijds voldoende klein zijn om verwerkt te kunnen worden tot waarde. En anderzijds moet de oplevering voldoende waarde hebben voor de stakeholders.

In een Definition of Ready leg je de afspraken vast die de Product Owner heeft gemaakt met het Team om bovenstaande problemen het hoofd te bieden.
Veelal heeft de Definition of Ready de vorm van een checklist waarmee de Product Owner punt voor punt kan nalopen of de User Story voldoet aan de gestelde eisen.

Hoe stel je een Definition of Ready op? Het gebruik van INVEST

Zoals aangegeven is de Definition of Ready de vastlegging van de afspraken tussen het Team en de Product Owner.
Een basis om het gesprek daarover aan te gaan en de Definition of Ready op te stellen is het acroniem INVEST. Dit acroniem staat voor:

Independent – Onafhankelijk, User Stories moeten zomin mogelijk afhankelijkheden hebben ten opzichte van andere User Stories. Ook probeer je afhankelijkheden met anderen buiten het Scrum Team te vermijden.
Negotiable – Onderhandelbaar. Er moet voldoende ruimte in de User Story zitten. Hierdoor komt er een gesprek op gang tussen de Developers en de Product Owner over de exacte oplevering. Dus geen in steen uitgehouwen set van eisen.
Valuable – Waardevol. De User Story moet waardevol zijn. Dit lijkt een open deur, maar het kan voorkomen dat een User Story die in een eerder stadium is opgeschreven, op het moment dat deze besproken wordt achterhaald is en geen waarde meer vertegenwoordigd.
Estimable – Inschatbaar. De Developers moeten voldoende informatie hebben over de wens van de stakeholder zoals deze beschreven is om in te kunnen schatten hoeveel moeite het gaat kosten om deze wens te verwezenlijken. Veelal wordt de inschatting door middel van relatieve inschattingen, bijvoorbeeld met Planning Poker, gedaan.
Small – Klein. De User Story moet klein genoeg zijn om binnen een Sprint opgeleverd te kunnen worden. Immers aan het einde van elke Sprint moet er een incrementeel deel van het project opgeleverd worden. User Stories waarvan de Developers inschaten dat de oplevering langer dan een Sprint gaat duren, moeten dus worden opgeknipt door de Product Owner.
Testable – Testbaar. Het opgeleverde werk moet af zijn en in principe aan de klanten geleverd kunnen worden. Dit betekent dat getest moet worden of alles goed opgeleverd is. Om te kunnen testen is het van belang dat de Product Owner duidelijke acceptatiecriteria beschrijft waaraan het opgeleverde werk moet voldoen om waardevol te zijn voor de Stakeholders.
Definition of Ready voor de Product Backlog
Deze INVEST-criteria kunnen dan de basis vormen voor een eigen Definition of Ready.
Gebruik deze criteria om samen te bepalen hoe je een en ander in de praktijk kunt toetsen. Elk Scrum Team zal op een andere manier naar de criteria kijken en een eigen Definition of Ready op stellen.
Vergeet ook niet om de Definition of Ready regelmatig, bijvoorbeeld tijdens de Sprint Retrospective, tegen het licht te houden en waar nodig aan te scherpen.

Vraag je je af hoe je met jouw team of organisatie slimmer kunt samenwerken a.d.h.v. Agile of Scrum? Volg dan een van onze trainingen of neem eens contact met ons op om vrijblijvend kennis te maken met een van onze ervaren Agile coaches. Je kunt ons bereiken via info@agilescrumgroup.nl of 020 2614 195.

Ook interessant:

Volg ons op LinkedIn (we delen onze blogs met je)

 

Over de auteur: Christiaan Kleczewski

Christiaan is Agile Coach en trainer. Zijn expertise ligt op het implementeren en begeleiden van Agile in organisaties en Scrum en andere raamwerken in teams. Dit doet hij op een pragmatische manier met aandacht voor de specifieke omstandigheden in de organisatie en de teams. Immers, organisaties en teams bestaan uit mensen en mensen zijn allemaal anders. Christiaan deelt zijn kennis en ervaring in blogs die regelmatig te lezen zijn op deze website.