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.
Vervolgens maken de Developers een inschatting over de zwaarte van de User Story, vaak door het spelen van planning poker.
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:
- Uitleg Scrum begrippen
- Wat is een User Story
- De Product Backlog: Alles Wat je Moet Weten (en een Template)
- Product Owner: de 5 belangrijke taken + een handig template
- Een Product Owner training volgen?
Volg ons op LinkedIn (we delen onze blogs met je)
