Backlog refinement en backlog grooming. Het zijn synoniemen die je tegenkomt in scrum en in agile. Zoals de namen al doen vermoeden, heeft het te maken met het op orde houden van de product backlog. Maar wat betekent dat precies? In dit artikel leg ik uit wat product backlog refinement is en hoe het werkt.

Korte samenvatting

Backlog refinement is een doorlopend proces om verbeteringen en verfijningen aan te brengen in de takenlijst van een project.
Dit proces is essentieel omdat het helpt om onduidelijkheden in taken en features te voorkomen, wat kan leiden tot verspilde tijd en middelen, of zelfs het opnieuw moeten doen van implementaties.
Een goed uitgevoerde backlog refinement kan ook budgettaire problemen voorkomen, zoals het onnodig toewijzen van te veel middelen aan bepaalde taken.

Wat is backlog refinement of backlog grooming

Product backlog refinement of “backlog grooming” vertaalt zich in het Nederlands naar het verfijnen van de product backlog.

Backlog refinement is de doorlopende activiteit om verbeteringen en verfijningen aan te brengen op de kaartjes of taken in je backlog.

Denk hierbij aan het (opnieuw) vaststellen van een gedeelde begripsvorming waarbij je kaartjes verduidelijkt en het (opnieuw) rangschikken van de taken. Maar ook activiteiten op de backlog en het (opnieuw) vaststellen van de benodigde tijd om taken te implementeren.

Het verfijnen van de backlog is in 2005 geïntroduceerd en sinds 2011 is backlog grooming ook echt onderdeel van de Scrum Guide.

Dit bevat het officiële raamwerk en methodologie van scrum, met bijvoorbeeld alle rollen en spelregels.

In 2013 werd besloten het officieel te vernoemen naar “refinement”. Dit omdat “grooming” in het urban dictionary nog een aantal andere betekenissen heeft waar je liever niet mee bezig bent als scrum of agile team.

Waarom is product backlog refinement belangrijk?

Je zal het vast herkennen. Je schrijft iets op, leest het een tijd later terug en je snapt niet goed meer wat je hebt opgeschreven.

Dit gebeurt bij projecten in het groot. Taken en features kraakhelder gedurende de user story mapping sessie.

Nu, een tijdje later blijkt alles toch onduidelijk of minder helder uitgewerkt zijn dan je toentertijd dacht.

Daarnaast kan de context van je project veranderd zijn en bijvoorbeeld de prioriteiten dus veranderen.

Zonder dat iedereen de features en taken goed begrijpt, riskeer je de kans om verkeerde dingen te implementeren, tijd en moeite daarmee te verspillen, en de implementatie deels over te moeten doen.

Wanneer je de hoeveel tijd en moeite die een activiteit kost ook verkeerd of slecht hebt ingeschat kan je project alsnog de soep in draaien. Ik kan je nu dat alvast vertellen: de tijd en moeite benodigd voor slecht gedefinieerde features of activiteiten in productontwikkeling valt nagenoeg nooit mee. Het valt bijna altijd tegen.

Dit kan uitdagingen meebrengen voor de Product Owner die uiteindelijk een bepaald budget heeft.

Daarnaast loop je het risico dat je “dure” activiteiten verward met “goedkope” activiteiten en dus soms juist ook te veel budget reserveert voor een taak.

Wanneer je de product backlog niet blijft ordenen aflopende van hoge prioriteit naar lage prioriteit, loop je het risico dat je aan de minder belangrijke dingen werkt terwijl de echt belangrijke dingen blijven liggen.

Dit is ook bij het ontwikkelen van een Minimal Viable Product (MVP) een grote uitdaging.

Als laatste zijn er ook nog een aantal positieve effecten te noemen:

Regelmatige backlog grooming zorgt voor een efficiënte sprint planning meetings omdat het alles helder is en iedereen op de hoogte is.

Daarnaast geeft een schone backlog een gevoel van grip. Het is gemakkelijk om te verdrinken in een eindeloze – rommelige – lijst aan kaartjes die nog open staan.

Alles samengenomen zorgt het er dus voor dat het team zo goed mogelijk in staat gesteld wordt goed uitgewerkte taken over te nemen in de sprints en die zonder twijfel en zo min mogelijk impediments of verstoringen uit te voeren.

Wie zijn betrokken bij backlog refinement?

Verplichte aanwezigheid bij product backlog refinement

Backlog refinement doe je in principe gezamenlijk. Tenminste moeten de Pr o duct Owner en één van de teamleden moeten aanwezig zijn bij backlog refinement om er iets zinnigs van te maken.

De Product Owner, omdat die een unieke informatiepositie heeft. De Product Owner is de enige die het hele project overziet.

De Product Owner kan (en moet!) dus goed meedenken bij bijvoorbeeld het prioriteren van taken.

Ook kan een Product Owner inschatten of de benodigde tijd voor een item past binnen het bredere projectbudget.

Teamleden moeten erbij zijn omdat zij uiteindelijk het werk moeten gaan doen.

Vanuit de expertise op een onderwerp kan een teamlid het beste taken definiëren en het beste een inschatting maken van de benodigde tijd.

Maak je een software product? Dan wordt het aanbevolen om ten minste één ontwikkelaar en één tester aan te laten sluiten bij een backlog refinement sessie. Zo heb je meerdere (multidisciplinaire) invalshoeken bij het verfijnen van de taken.

Geen verplichte aanwezigheid maar wel handig bij product backlog refinement

De Scrum Master’s aanwezigheid is niet verplicht. Wel kan het veel helpen de Scrum Master toch aan te laten sluiten.

De Scrum master kan de gesprekken leiden en het doel voor ogen houden.

Dit kan bijdragen aan een meer effectieve product refinement.

Het kost echter ook tijd van de Scrum Master. Zoek hierin met het team de juiste balans.

Je kan ook overwegen om een externe “facilitator” aan te stellen. Iemand die onbevangen en zonder ander belang naar het project kan kijken.

Dat kan helpen in “lastige discussies” tussen de product owner en teamleden. Dit kan de zuiverheid en objectiviteit van de product backlog refinement te goede komen.

Hoe bereid je een sessie goed voor?

Voordat je start kan het helpen als de Product Owner de backlog even prioriteert aan de hand van de grootste behoeften van de klant.

Daarna is het handig om met iedereen betrokken bij de backlog refinement te kijken naar de activiteiten of stories waarvan de verwachting is dat deze niet af komen in de huidige sprint.

Zo pak je het meeste laaghangende fruit.

Wanneer hou je een product backlog refinement?

Product backlog refinement zijn geen officiële meetings. Je doet het dus doorlopend. Daar zit ook het risico. Je kan het ook doorlopend niet doen.

Backlog grooming is namelijk een beetje als de vaat doen.

Wast iedereen netjes z’n vaat af, hoef je niet zo veel vaat in 1 keer te wassen. Doet niemand de vaat? Dan kan je de rest van je keuken niet meer gebruiken.

Hoe vaak je refinement moet doen hangt – wat mij betreft – af van de volgende punten:

Hoe goed user stories gemapt zijn. Heeft alles bijvoorbeeld ECHT goede acceptance criteria?
De netheid van werken binnen het team. Het is dus net als afwassen. Sommige teams zullen een heel schoon aanrecht hebben en andere teams hebben altijd wat rommel liggen.
De complexiteit van het project
Het aantal vlieguren van de teamleden en het team als geheel gemaakt hebben. Kan je met elkaar lezen en schrijven? Dan heb je soms letterlijk aan “1 woord genoeg”. In andere gevallen is het noodzakelijk om zaken verder uit te werken.

Hoeveel tijd ruim je in voor product backlog refinement?

De Product Owner zit in principe niet in de tijdsberekeningen van de sprint. De product Owner kan dus in principe zo veel tijd besteden als nodig is.

Voor teamleden is dit anders. Een “rule of thumb” die ik tegenkom is dat men stelt dat er niet meer dan 10% van de sprinttijd naar product backlog refinement mag gaan.

Dat is o.b.v. 40-urige werkweken dus maximaal 4 uur over de week verspreid. Het kan geen kwaad deze tijd te timeboxen net als andere scrum activiteiten zodat je zeker weet dat er ruimte voor gereserveerd is.

Of je 4 uur nodig hebt, dat hangt af van de bovenstaande punten. Het is gemakkelijk om deze tijd als niet productief te zien. Het voelt toch een beetje als “corvee”.

Toch pluk je er op de lange termijn echt de vruchten van en ik raad agile en scrum teams echt aan het structureel te doen en er een serieuze hoeveelheid tijd voor te reserveren. Is er minder tijd nodig? Top.

Hoe doe je backlog refinement handig?

Je kan binnen scrum en agile op duizend-en-één manieren je project managen. Ik raad je altijd aan dit te doen via projectmanagement software die geschikt is voor agile en scrum.

Zelf gebruik ik hiervoor bijvoorbeeld ClickUp.

ClickUp is overzichtelijk en kan je gemakkelijk aansluiten op praktisch alle andere tools die je veel zal gebruiken tijdens je project.

Je kan hier eigenlijk alles wat je in een agile project wil doen goed en overzichtelijk doen via verschillende Kanban borden.

Denk hierbij aan het mappen van userstories, het inplannen van sprints, of het houden van retrospectives.

Ook kan je dus erg gemakkelijk de brug maken tussen user story mapping en de backlog.

De backlog kan je zodoende ook gemakkelijk bijhouden en verder uitwerken op een overzichtelijke manier.

ClickUp is een freemium tool, en je krijgt – in tegenstelling tot bijvoorbeeld Trello – enorm veel features in de gratis variant om te proberen.

Daarna kost het voor een heel team per teamlid een paar euro per maand.

Ken je ClickUp nog niet? Dan raad ik je aan het in ieder geval even te proberen.

Beste planning en project software van nu
Krachtige en toegankelijke tool
Slimme automation
Geen creditcard of aanbetaling nodig

Probeer gratis

Wil je meer weten over ClickUp? Lees dan onze review over ClickUp.

Samengevat: backlog refinement is de stille kracht van scrum en agile

Ik zie backlog refinement als één van de grote stille krachten in scrum en agile.
Gebeurt het doorlopend en goed, dan merkt niemand het op. Je zal er weinig complimenten voor krijgen.

Doe je het slecht en onvoldoende?

Voor dat je het weet staat de hele keuken vol vieze vaat en is iedereen in paniek.