slim
samen
werken

Product Backlog Refinement meeting: volledige uitleg van deze onofficiële meeting

Wat is Product Backlog Refinement?

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 ingaat 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

Klik voor een grotere versie

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, kan het Development Team 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 kan het Development Team accurate inschattingen maken.

Goede inschattingen zijn van groot belang voor de Product Owner en het Development Team.
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.
Het Development Team gebruikt 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 kan het Development Team 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.

scrum trainingen

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 het Development Team 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 het Development Team. Het team moet een compleet beeld krijgen van de Story. Het Development Team moet 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 het Development Team geeft hierop feedback. Hierdoor kan de User Story waar nodig aangepast en verduidelijkt worden.
Vervolgens maakt het Development Team een inschatting over de zwaarte van de User Story, vaak door het spelen van planning poker.

Planning Poker voor Product Backlog Refinemnet
Ook kan het Development Team 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 het Development Team kan gefocust verder werken aan het leveren van waarde.

Ook interessant:

Volg ons op LinkedIn (we delen onze blogs met je) Of deel het in je netwerk:

LINKEDIN
Follow by Email
Schrijf je in om om de week de nieuwste Agile inzichten te ontvangen