Product Backlog Refinement: het ventieldopje en 5 anti-patterns

Product Backlog Refinement is voor het Scrum Team een doorlopende activiteit, geen apart event op de agenda. Maar het is wel de activiteit die het verschil maakt tussen een team dat steeds halverwege blijft hangen, en een team dat sprint na sprint voorspelbaar levert. Dit artikel gaat niet over de theorie uit de Scrum Guide. Het gaat over wat we in vijftien jaar coaching zien werken, met het ventieldopje als kompas voor INVEST en vijf anti-patterns die je waarschijnlijk herkent.

TL;DR. Refinement is het uitwerken van wensen naar behapbare stukken die het development team kan oppakken én opleveren. Doel: kleinere spreiding op deliverables door betere werkplanning, helderdere verwachtingen en eerder zicht op risico's. Nominaal maximaal 10% van de team-capaciteit; in de praktijk vaak 2 x 2 uur per twee-wekelijkse sprint. De PO leidt, het hele team draagt bij, en de Scrum Master grijpt in als de timebox uitloopt.

Wat is Product Backlog Refinement?

Product Backlog Refinement is het continue proces waarin het Scrum Team items in de Product Backlog verfijnt: opdelen in kleinere stukken, herformuleren met scherpere acceptance criteria, schatten en herprioriteren. Geen apart Scrum-event, maar een doorlopende activiteit. In de praktijk plant het team er meestal twee momenten per sprint voor in.

De vroegere term "backlog grooming" wordt steeds minder gebruikt. De huidige term in de Scrum Guide is "refinement" - korter, en zonder de ongemakkelijke connotaties die "grooming" sinds de jaren 2010 heeft gekregen.

Wie doet wat: de Product Owner is verantwoordelijk voor de inhoud van de backlog en leidt het gesprek over wát er moet komen. Het hele team (Developers + Scrum Master) draagt bij aan hoe items kunnen worden opgedeeld, geschat en welke risico's er spelen. De Scrum Master bewaakt het proces en grijpt in als de timebox uitloopt of als één persoon te dominant is.

Wanneer items "ready" zijn: een refinement-sessie eindigt idealiter met items die voldoen aan de Definition of Ready van het team. Dat betekent: helder genoeg om in te schatten, klein genoeg om in één sprint af te ronden, en met afspraken over hoe je weet of het klaar is. Zie verderop het onderdeel over de INVEST-criteria.

Wat refinement écht oplevert

Veel teams zien refinement als 'tijd vrijhouden voor de PO'. Dat is een hele beperkte kijk. Goede refinement levert het team op drie dimensies waarde:

1. Betere werkplanning

Hoe beter de refinement, hoe kleiner de spreiding op deliverables. Items zijn helder, opgedeeld in stukken die in een sprint passen, en geschat met begrip van de complexiteit. Sprint planning gaat sneller omdat het denkwerk al gedaan is. Het team kan met meer vertrouwen committen op wat ze de komende sprint gaan opleveren.

2. Heldere verwachtingen

Door tijdens refinement het gesprek te voeren krijgt de PO (en daarmee de klant) veel meer detail over wat überhaupt mogelijk is. Niet alleen "kan dit?", maar ook "wat kost dit ten opzichte van iets anders, en wat zijn de afhankelijkheden?" Stakeholders die later in het proces aanhaken krijgen consistente informatie omdat het team gezamenlijk het begrip heeft opgebouwd.

3. Risicomanagement

Refinement is de plek waar afhankelijkheden, technische schulden en onduidelijkheden vroeg op tafel komen. Een item dat in eerste instantie "klein" leek, blijkt bij doorvragen drie externe systemen te raken. Dat ontdek je liever tijdens refinement dan halverwege een sprint waar je al gecommit hebt. Risico's zichtbaar maken is geen vertraging - het is voorkomen van veel grotere vertraging later.

Naarmate een team rijper wordt in refinement, neemt de voorspelbaarheid toe. Dat is het echte rendement: niet een veloctity-getal dat omhoog gaat, maar een team dat sprint na sprint levert wat het belooft.

Wat doe je tijdens refinement?

Concreet zijn er vijf activiteiten die in een refinement-sessie kunnen plaatsvinden. Niet allemaal voor elk item, en niet in een vaste volgorde:

1. Items opdelen. Te grote stories splitsen in kleinere die in één sprint passen. Vaak het belangrijkste werk.
2. Items herformuleren. Acceptance criteria scherper maken. Vragen beantwoorden zoals "wat is hier eigenlijk klaar?" en "voor wie is dit waardevol?"
3. Items schatten. Story points, T-shirt sizing, of een andere relatieve schaal. Het hele team schat mee, niet alleen de seniors.
4. Items prioriteren. De PO ordent op waarde, samen met inzicht van het team over technische volgorde en afhankelijkheden.
5. Risico's en afhankelijkheden identificeren. Welke items raken andere teams, externe systemen, of onbeschikbare expertise?

INVEST: het ventieldopje en de twee valkuilen

De meest gebruikte checklist voor goede backlog items is INVEST, bedacht door Bill Wake. Een item is INVEST-compliant als het is: Independent, Negotiable, Valuable, Estimable, Small en Testable.

Het uitleggen van INVEST in een training werkt het beste met een voorbeeld dat iedereen direct visualiseert. Wij gebruiken het automobiel-ventieldopje.

Het ventieldopje als kompas

Stel je voor: een team krijgt de opdracht "bouw een auto". Dat is een huge epic - geen sprake van dat dit in een sprint past. Een hele auto opdelen begint met grote brokken: motor, carrosserie, wielen. Het wiel alleen al, met al zijn onderdelen, is nog steeds niet in één sprint te realiseren. Maar het ventieldopje van het wiel - dat klein zwart kapje dat het ventiel afdekt - dáár kan iedereen direct een beeld bij bedenken. Hoe ziet het eruit? Wat doet het? Wat moet er getest worden? Een ventieldopje is in een dag te maken.

Loop er INVEST overheen:

• I - Independent. Het ventieldopje kan los van de rest gemaakt en geleverd worden. ✓
• N - Negotiable. De vorm, het materiaal (plastic of metaal), de kleur, de schroefdraad: alles is nog te bespreken. ✓
• V - Valuable. Op zichzelf bescheiden waardevol, maar zonder ventieldopje verlies je luchtdruk - dus functioneel onderdeel. ✓
• E - Estimable. Hoe kleiner een item is, hoe beter de inschatting. Een ventieldopje is goed inschatbaar. ✓
• S - Small. Past makkelijk in een sprint - sterker nog, er passen veel ventieldopjes in een sprint. ✓
• T - Testable. Helder testbaar: past hij op het ventiel, houdt hij lucht binnen, ziet hij eruit zoals afgesproken. ✓

Het ventieldopje voldoet aan alle INVEST-criteria. Het is een tastbaar voorbeeld van "klein genoeg" om als één goede user story te zien.

De Small-valkuil: "het past in een sprint"

Veel trainees denken dat "Small" betekent dat een user story in een sprint moet passen. Dat is een onderschatting. Onze stelregel: er moeten met gemak meerdere user stories in een sprint passen. Eén user story is geen sprint vol werk - het is een afgerond stukje binnen een sprint.

Als je item zo groot is dat je denkt "dit is mijn sprint", dan is het waarschijnlijk een epic die je moet opdelen. Het ventieldopje is geen sprint vol werk; het is een dagje werk binnen een sprint van twee weken.

De Negotiable-valkuil: het HOE in de acceptatiecriteria

De achilleshiel van veel Product Owners is dat ze niet alleen het WAT bepalen, maar stiekem ook het HOE willen voorschrijven. Vaak gebeurt dat via acceptatiecriteria die zo gedetailleerd zijn dat het team eigenlijk geen ontwerpkeuzes meer kan maken. "Het ventieldopje moet zwart zijn, van polyacrylaat, met M8-schroefdraad, en de afdichting moet een rubberen O-ring op positie 2,3mm zijn."

Wat we PO's meegeven: laat het zoveel mogelijk los. De acceptatiecriteria beschrijven wat er klaar is (de buitenkant: het houdt lucht binnen), niet hoe het is gebouwd (de binnenkant: M8-schroefdraad en O-ring). Negotiable gaat over het team de ruimte geven om zelf de beste technische keuze te maken. Een PO die alle ontwerpkeuzes vastlegt in acceptatiecriteria, neemt feitelijk het ontwerpwerk over.

5 anti-patterns die refinement laten mislukken

Net als bij elk Scrum-event zijn er patronen die zich herhalen bij teams die net beginnen met refinement, of bij teams waar het is verzand. Vijf die we het vaakst zien:

1. De PO praat 80% van de tijd, devs zitten achterover

De PO is enthousiast over een feature en vertelt het hele verhaal. Devs luisteren, knikken, stellen geen vragen. Refinement is geen presentatie - het is een gesprek waarin het team meedenkt. Sterker nog: refinement is een uitgelezen kans voor de PO om werk juist deels uit handen te geven. De devs hebben de technische kennis om te zien wat haalbaar is, waar afhankelijkheden zitten, en hoe te splitsen.

Wat we PO's meegeven: ga zoveel mogelijk achterover zitten. Stel een vraag, wacht op antwoord. Laat het team de splitsing voorstellen. Als jij meer praat dan een willekeurige dev, is iets fout.

2. Items worden te weinig gedetailleerd ("dat pak ik wel op")

Een senior teamlid zegt tijdens refinement "dat pak ik wel op" en het item gaat naar de volgende. Vier sprints later blijkt: alleen die senior weet wat er moest gebeuren, de details zijn nooit op tafel gekomen, en de rest van het team kan het niet overpakken.

Wat we teams aanraden: elk item moet zoveel detail krijgen dat een ander teamlid het ook zou kunnen oppakken. "Dat pak ik wel op" is geen acceptable einde van een refinement-discussie - het is het signaal om door te vragen.

3. Items niet granulair genoeg → sprint planning loopt vast

Items worden inschat als "vrij groot, M of L". Bij sprint planning blijken die items dan toch te groot - er passen er minder in dan gedacht, of ze passen niet eens. Resultaat: planning loopt 4 uur in plaats van 1, en het team commit op te veel werk dat ze in de sprint niet kunnen leveren.

Wat we teams aanraden: als een item nog "L" of groter is na refinement, splits het verder op. Als splitsen lastig is, dan is de discussie waarschijnlijk dat het concept nog niet helder genoeg is. Stop met inschatten en herformuleer.

4. Niet alle devs schatten mee

Bij Planning Poker stemmen alleen de seniors actief mee. De juniors stemmen niet, of stemmen mee met wat de seniors zeggen. Het inzicht dat schattingen geven - waar wijken teamleden van elkaar af, en waarom? - gaat dan verloren.

Wat we teams aanraden: iedereen schat, ook degene die het werk waarschijnlijk niet zelf gaat doen. Als de schattingen sterk uiteenlopen (één geeft 2, een ander 8), dán is dat een gesprek. Misschien zit er een aanname onder die uitgesproken moet worden.

5. De PO houdt timebox niet bij → asymmetrische items

Het eerste item krijgt 30 minuten aandacht, de daaropvolgende vijf elk 2 minuten. Het lijstje is "afgewerkt" maar de meeste items zijn nauwelijks gerefined. Volgende sprint blijken die items niet "ready".

Wat we teams aanraden: spreek vooraf af hoeveel tijd er per item beschikbaar is, bijvoorbeeld 15-20 minuten per item bij een sessie van een uur. Loop je er overheen, dan is dat een signaal: óf het item is groter dan gedacht (parkeer en behandel volgende refinement), óf er is een fundamenteler gesprek nodig dat niet in refinement past. In beide gevallen: roep de Scrum Master erbij om te helpen bewaken.

Story points, T-shirt sizing, en bias

Story points zijn voor veel teams een struikelblok. De grootste fout: niet begrijpen dat story points relatieve grootte aangeven, niet absolute tijd. Een story van 5 punten is niet "5 uur" of "5 dagen" - hij is "groter dan 3, ongeveer als 5". Story points zijn initieel bedoeld om over alle user stories en epics heen een idee te krijgen van de Onderlinge Relatieve Grootte, zodat het team later, in de sprint planning, een betere voorselectie kan maken.

T-shirt sizing als alternatief

In de refinement-fase zelf gebruiken we vaak T-shirt sizing in plaats van story points: S(1), M(2), L(3). Of de klassieke Likert-schaal: XS, S, M, L, XL. Dat geeft genoeg onderscheid om te kunnen prioriteren zonder de schijn-precisie van getallen. Sprint planning kun je later alsnog vertalen naar punten voor velocity-tracking, als het team dat zinvol vindt.

Bias bij beginnende teams

Bij teams die net beginnen met schatten zien we vaak bias door senior teamleden. De senior stemt 3, en plotseling stemt iedereen 3. Daarom: stem in eerste instantie gesloten, zoals bij Planning Poker. Iedereen zet zijn schatting op tafel, en dan tegelijkertijd onthullen. Dat haalt de groepsdruk eruit.

Bij echt nieuwe teams kan het helpen om de Scrum Master als facilitator erbij te halen. Niet om mee te schatten, maar om de dynamiek te observeren en patronen aan te kaarten - bijvoorbeeld dat dezelfde junior elke keer mee-stemt met dezelfde senior.

Cadans: de 10%-regel en ons donderdag/woensdag-schema

De Scrum-norm is dat de PO maximaal 10% van de capaciteit van het team mag gebruiken voor refinement. Bij een werkweek van 40 uur komt dat neer op 4 uur per teamlid per week. In de praktijk is dat erg veel. Voor een team van 6 devs zou dat 24 uur refinement per week zijn.

Wij hanteren in de meeste teams een ander schema: 2 uur in week 1 + 2 uur in week 2 (bij een sprint van twee weken). Dat is per teamlid 4 uur per sprint, oftewel ruim binnen de norm. Welke dagen?

Week 1: liefst donderdagmiddag

In de eerste week is het team net begonnen aan de sprint. Maandag en dinsdag zijn voor het opstarten en tractie krijgen op de gecomitte items. Refinement op maandag-of-dinsdag haalt het team uit die ritme. Donderdag is meestal het beste moment: het team zit lekker in de sprint, heeft hoofdruimte, en kan met aandacht naar de toekomst kijken zonder de huidige sprint te missen.

Week 2: liefst woensdag

In de tweede week werkt het team toe naar de Sprint Review op vrijdag. Donderdag of vrijdag refinement plannen is zinloos - het team is dan focused op de review. Woensdag is een goed compromis: nog niet te dicht op de review, en wel laat genoeg dat de eerste week-refinement is verwerkt.

Dit schema is geen wet. Voor teams met andere ritmes kan het anders. Maar het uitgangspunt blijft: refinement plannen op de momenten dat het team het minst kost aan focus, en niet als een dagelijkse interruptie.

Een refinement-agenda die werkt

Voor wie een concrete agenda zoekt: dit is wat in onze trainings goed werkt voor een refinement-sessie van een uur:

Onderdeel	Tijd	Wat gebeurt er
Check-in + acties vorige refinement	5 min	Wat is sinds vorige refinement gebeurd? Welke items zijn nu ready?
Hoog-prio item 1	15 min	Opdelen, acceptance criteria scherpen, schatten
Hoog-prio item 2	15 min	Idem
Hoog-prio item 3	15 min	Idem
Risico's & afhankelijkheden	5 min	Welke items raken andere teams of externe systemen?
Top-van-backlog check	5 min	Hoeveel items zijn nu 'ready' voor de komende sprints? Wat moet er nog?

Totaal: 60 minuten. Voor 2 sessies per sprint (donderdag + woensdag) ben je gemiddeld 4 items per sprint goed door, plus tijd voor risico-discussies. Voor teams die werken met grotere of complexere items kun je de items-blokken verlengen of het aantal items per sessie verlagen.

Refinement in remote en hybride teams

Refinement in remote teams werkt anders dan een retrospective - het is veel meer tool-gedreven. De inhoudelijke discussie zit grotendeels in het backlog-tool (Jira, Azure DevOps), niet op een sticky-board. Maar het sociale aspect blijft belangrijk: een refinement waarin alleen iemand het scherm deelt en de rest tikkert, levert weinig op.

• Iedereen op camera. Geen luistermodus. Refinement vereist actief meedenken; zonder gezichten verlies je daarop het zicht.
• Backlog-tool gedeeld op één scherm. Jira of Azure DevOps op het scherm, voor iedereen hetzelfde beeld. Niet ieder zijn eigen browser, want dan kijken mensen weg.
• Planning Poker-tool voor schatten. Gebruik een aparte tool (PlanningPokerOnline, Scrum Poker, etc.) om gesloten te stemmen. Dat voorkomt de bias die in remote-omgevingen nog sterker is dan fysiek.
• Hou de meeting kort. Een uur is genoeg voor remote refinement; daarna verliest iedereen scherpte. Liever twee sessies van een uur dan één van twee uur.

Veelgestelde vragen

Wat is het verschil tussen refinement en grooming?

Dezelfde activiteit, andere term. "Grooming" was de gangbare term in de jaren 2010, maar wordt steeds minder gebruikt vanwege ongemakkelijke connotaties. De huidige Scrum Guide gebruikt "refinement". Inhoudelijk verandert er niets.

Hoe vaak doe je refinement?

Geen vast voorschrift. De norm is dat de PO maximaal 10% van team-capaciteit gebruikt voor refinement. In de praktijk werkt voor twee-wekelijkse sprints meestal 2 sessies van 1 uur per sprint, op donderdag (week 1) en woensdag (week 2).

Wie organiseert refinement?

De Product Owner is verantwoordelijk voor de inhoud en plant de sessies. De Scrum Master kan helpen met facilitatie, vooral bij beginnende teams of als de timebox uitloopt. De Developers nemen actief deel.

Hoeveel items moet 'ready' zijn voor sprint planning?

Een vuistregel: minimaal anderhalf tot twee sprints aan ready items in de top van de backlog. Dat geeft het team flexibiliteit als er tijdens de sprint iets verandert, en de PO ruimte om te prioriteren zonder dat het team op iets onafgerond stuit.

Mag de Scrum Master refinement leiden?

De Scrum Master kan refinement faciliteren, vooral bij teams die ermee beginnen. De inhoudelijke verantwoordelijkheid voor de backlog blijft bij de Product Owner. In rijpere teams trekt de Scrum Master zich vaak terug en doet de PO de regie.

Wat als de PO geen tijd heeft voor refinement?

Dan is dat een fundamenteel probleem dat het team moet adresseren. Refinement is geen optionele tijdsinvestering - zonder refinement loopt het team vast in de sprints. Bespreek dit in een retrospective. Een PO die structureel te weinig tijd voor het team heeft, ondersteunt de Scrum-rol niet zoals het bedoeld is.

Refinement leren faciliteren

Refinement effectief faciliteren is een vak dat zowel de PO als Scrum Master raakt. De PO moet leren het werk uit handen te geven; de Scrum Master leert de patronen herkennen die het event laten mislukken. Onze Product Owner Training besteedt uitgebreid aandacht aan refinement-facilitatie, inclusief de anti-patterns en INVEST-toepassing uit dit artikel.

Eerst meer lezen? Lees over de rol van de Product Owner die refinement leidt, of bekijk hoe refinement past in het bredere Scrum-framework via Wat is Scrum?