Product Backlog Refinement

Volgens de Scrum Guide geeft de Product Backlog Refinement invulling aan de Product Backlog; details worden aangebracht, inschattingen worden gemaakt en de Product Backlog wordt geordend. Echter wordt geen duidelijkheid gegeven over de manier waarop de Product Backlog Refinement zou moeten plaatsvinden. Daarom krijgt het Scrum Team de verantwoordelijkheid te bepalen hoe en wanneer dit gebeurt.

Ontdekken van afhankelijkheden

Een van de doelen van het opstellen van een Product Backlog Refinement is het achterhalen van afhankelijkheden. Denk hierbij bijvoorbeeld aan afhankelijkheden tussen User Stories of dat de Developers nodige personen missen, waardoor zij afhankelijk zijn van anderen die niet in het team zitten. Omdat dit proces vroegtijdig gebeurt kunnen deze zaken opgelost worden alvorens zij problemen opleveren.

Zo kan een Product Owner besluiten een User Story anders te verwoorden, zodat deze niet meer afhankelijk is van een andere User Story en op zichzelf een losstaande taak is.

Inschattingen

Een ander doel van het samenstellen van de Product Backlog Refinement is het compleet maken van User Stories door details aan te brengen. De Product Owner plaatste eerder in het werkproces deze korte taakomschrijvingen op de Product Backlog. De aangebrachte details maken het voor de Developers gemakkelijker in te schatten hoeveel tijd precies nodig is om een User Story af te ronden.

Het maken van juiste inschattingen is zeer belangrijk voor zowel de Product Owner als de Developers. Aan de hand van de bepaalde tijd per User Story heeft de Product Owner de mogelijkheid een release planning op te stellen. Omdat hij precies weet welke User Stories meegaan in de volgende release, kan hij inschatten wanneer een (deel)product opgeleverd kan worden. Voor de Developers zijn inschattingen van de User Stories ook belangrijk: zo kunnen zij samen bepalen hoeveel taken zij op zich zullen nemen in de komende sprint. Maar ook het bepalen van de Product Goal is goed voor het inschatten van de doelen van het Scrum team op lange termijn. De Product Goal beschrijft de toekomstige staat van het product, pas als het Product Goal behaald (of verworpen) is, kan het team aan een nieuw Product Goal werken.

Voorbereiden van de meeting

Om de Product Backlog Refinement te laten slagen is een goede voorbereiding nodig. Allereerst moet de Product Owner bepalen welke User Stories in detail uitgewerkt dienen te worden. Het is van belang niet te ver van te voren verschillende User Stories uit te werken, omdat het geen zekerheid is dat deze User Stories meegenomen worden in de komende sprints. Het is namelijk zo dat slechts de User Stories met de hoogste prioriteit zullen worden behandeld. Denk eraan: werken met Scrum vergt veel van je flexibiliteit. Werk daarom alleen die User Stories uit die voor de eerstvolgende 2 of 3 sprints op de planning staan.

Vervolgens is het de taak aan de Product Owner ervoor te zorgen dat de User Stories goed beschreven zijn, zodat alle leden van het Scrum Team deze direct begrijpen. Daarnaast moet het voor de Developers helder zijn aan welke eisen de taak moet voldoen. Hierom zullen van te voren genoeg acceptatiecriteria per User Story opgesteld moeten worden.

Alles weten over de Product Backlog? Bekijk onze animatie video.

De Product Backlog Refinement meeting

Het is een goed gebruik om, net als bij alle andere meetings uit het Scrum Framework, een maximale tijd toe te wijzen aan Product Backlog Refinement. Een veelgebruikte richtlijn daarvoor is maximaal 10% van de gehele tijd die aan één sprint besteed wordt. Ofwel, wanneer een Scrum Team fulltime bezig is met een Sprint, limiteer je de Product Backlog Refinement tot maximaal 4 uur per week

Daarnaast dienen alle leden van het Scrum Team aanwezig te zijn tijdens de meeting. Dit is belangrijk, omdat de Product Owner alle User Stories zal uitleggen. Zo krijgen de Developers een goed beeld van de geplande taken en krijgen zij de mogelijkheid tot het geven van feedback op de User Stories. Indien nodig kan een onduidelijke User Story aangepast worden. Afsluitend zijn de Developers verantwoordelijk voor het inschatten van de te besteden tijd per User Story. Dit wordt gedaan aan de hand van planning poker.

De Product Backlog Refinement kan door de Developers ook ingezet worden als taakverdeler, waarbij User Stories worden opgedeeld in kleinere werkzaamheden. Het team zal hiermee voorbereidend werk leveren voor de Sprint Planning, waardoor deze meeting soepeler zal gaan verlopen.

Ofwel, de Product Backlog Refinement meeting brengt veel voordelen met zich mee. Zo worden verwachtingen van het project in een vroeg stadium duidelijk, worden User Stories onderverdeeld in deeltaken en worden onduidelijkheden weggenomen, zodat de Developers zich kunnen focussen op de komende sprint.

Ook interessant:
Sprint Planning
Daily Stand-Up Meeting
Sprint Retrospective