slim
samen
werken

Product Backlog Refinement: volledige uitleg van de meeting (+ template download)

Product Backlog Refinement wordt in de Scrum Guide, de ‘Scrum spelregels’, beschreven als het toevoegen van detaillering, inschatting en structuur aan de Product Backlog.
Maar waar de Scrum Guide in detail gaat op diverse andere meetings zoals de Sprint Planning, de Sprint Review en de Sprint Retrospective, zegt de gids niets over hoe de Product Backlog Refinement moet plaatsvinden. Het is aan het Scrum Team om te bepalen hoe en wanneer deze Product Backlog Refinement plaatsvindt.

Product Backlog Refinement om inschattingen te maken

Zoals aangeven gaat het bij Product Backlog Refinement om het toevoegen van detail aan de User Stories die door de Product Owner op de Product Backlog zijn geplaatst.

Door meer te weten over de User Stories en deze tot in het kleinste detail te begrijpen, kunnen de Developers (voorheen het Development Team genoemd) inschatten hoe groot de User Story is. Omdat ze precies weten wat de Product Owner verlangt en exact weten welke werkzaamheden nodig zijn om deze af te maken kunnen de Developers accurate inschattingen maken.

Goede inschattingen zijn van groot belang voor de Product Owner en de Developers.
De Product Owner kan aan de hand van alle ingeschatte User Stories op de Product Backlog een release planning opstellen. Hij weet per slot van rekening welke User Stories hij wil opnemen in de komende release. Aan de hand van de som van de inschattingen kan hij een gedegen voorspelling maken van het moment dat kan worden opgeleverd.
De Developers gebruiken de inschattingen om te kunnen bepalen aan hoeveel User Stories zij zich in de volgende sprint kunnen committeren.

Product Backlog Refinement helpt afhankelijkheden ontdekken

Een ander doel van de Product Backlog Refinement is het in een vroeg stadium ontdekken van eventuele afhankelijkheden. Dit kunnen afhankelijkheden zijn tussen Stories. Ook kunnen de Developers erachter komen dat zij afhankelijk zijn van anderen buiten het team.
Door dit vroegtijdig te ontdekken kunnen de afhankelijkheden worden weggenomen.

De Product Owner kan bijvoorbeeld een User Story herschrijven zodat de afhankelijkheid verdwijnt.
In het geval van externe afhankelijkheden kan er in een vroeg stadium contact worden opgenomen met de externe personen. Dan kunnen er afspraken worden gemaakt over het werk dat door hen gedaan moet worden.

Voorbereiding Product Backlog Refinement meeting

Een goede Product Backlog Refinement meeting staat of valt met een goede voorbereiding. De Product Owner moet duidelijk voor ogen hebben welke User Stories voor Product Backlog Refinement in aanmerking komen.
Hierbij is het belangrijk om niet te ver van tevoren User Stories te gaan refinen. Het zou namelijk zo maar kunnen dat de User Stories nooit in een sprint worden opgenomen. Alleen Stories die hoog genoeg op Product Backlog staan worden immers opgeleverd.
Refine daarom alleen User Stories die in de komende 2 of 3 sprints aan bod komen.
Vervolgens is het belangrijk dat de User Stories goed en helder geformuleerd zijn. De Product Owner moet ervoor zorgen dat deze duidelijk genoeg zijn. Ook moeten er voldoende acceptatiecriteria per User Story zijn. Hierdoor is het voor de Developers duidelijk wat de kwaliteitseisen zijn waaraan voldaan moet worden.

De Product Backlog Refinement sessie

De Product Backlog Refinement sessie is net als de andere meetings in Scrum getimeboxt. De Scrumguide gaat uit van het reserveren van 10% van de totale Sprinttijd voor de Refinement. In een Sprint waaraan fulltime wordt gewerkt, zou de time-box dus maximaal 4 uur per week zijn.
Het gehele Scrum Team is aanwezig bij de Product Backlog Refinement sessie.
De Product Owner legt een voor een de User Stories uit aan de Developers. Zij moeten een compleet beeld krijgen van de Story. De Developers moeten weten wat er gedaan moet worden en wat de kwaliteitseisen zijn. Deze worden gevormd door de Definition of Done en de acceptatiecriteria.

De Product Owner legt de Story uit en de Developers geven hierop feedback. Hierdoor kan de User Story waar nodig aangepast en verduidelijkt worden.
Vervolgens maken de Developers een inschatting over de zwaarte van de User Story, vaak door het spelen van planning poker.

Planning Poker voor Product Backlog Refinemnet
Ook kunnen de Developers de Product Backlog Refinement meeting gebruiken om alvast na te denken hoe zij de Story gaan opdelen. De taken kunnen dus al worden bepaald. Hierdoor wordt een voorzet genomen op de Sprint Planning, deze zal hierdoor efficiënter verlopen.

Een goede Product Refinement zorgt er dus voor dat er vroeg genoeg duidelijk is wat er gedaan moet worden. Daarnaast is bekend hoe deze Stories ingeschat zijn en opgedeeld kunnen worden.
Onduidelijkheden en afhankelijkheden zijn weggenomen en de Developers kunnen gefocust verder werken aan het leveren van waarde.

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.