Verfijning van de backlog (grooming): frequentie, verantwoordelijkheid en wat „klaar” precies inhoudt

Het verfijnen van de backlog, nog steeds vaak ‘grooming’ genoemd, is het voortdurende proces waarbij productbacklog-items worden voorbereid vóór de sprint waarin ze zullen worden geïmplementeerd: verduidelijken wat elk item inhoudt, te omvangrijke items opsplitsen, acceptatiecriteria toevoegen, de omvang ervan inschatten en ze op prioriteit gesorteerd houden. Het is niet zozeer een eenmalige vergadering als wel een gewoonte. En het is het subtiele verschil tussen een rustige sprintplanning en een sprintplanning die uitmondt in een twee uur durende discussie.

Is het nu wel of geen ceremonie?

Technisch gezien niet. In de Scrum Guide wordt het verfijnen van de backlog niet als een van de evenementen genoemd. Het wordt daarin beschreven als een doorlopende activiteit die niet meer dan ongeveer 10 % van de capaciteit van de ontwikkelaars in beslag mag nemen. De puristen hebben het dus bij het rechte eind: het is geen ceremonie.

En toch is de gids van Asana over agile ceremonies getiteld „4 evenementen + backlogverfijning”, en de meeste werkteams reserveren voor de verfijning een vast tijdstip op de agenda en voeren deze uit zoals elke andere ceremonie. Beide kampen wijzen vanuit verschillende invalshoeken op dezelfde waarheid: verfijning is geen formeel evenement, maar het is doorgaans de juiste keuze om het wel als zodanig te behandelen. Slaat u het over, dan verdwijnen de kosten niet. Ze verschuiven alleen naar sprintplanning, waar ze duurder zijn en op een minder geschikt moment plaatsvinden.

Wat verfijning nu eigenlijk inhoudt

Door verfijning worden ruwe backlog-items (vaak een titel en een vage wens) omgezet in bruikbare items. In de praktijk bestaat dit uit vier stappen, die continu worden doorlopen:

• Verduidelijk. Maak van „de onboarding verbeteren” een doelstelling met een duidelijke strekking en acceptatiecriteria waaraan het team kan toetsen of dit is gerealiseerd.
• Opsplitsen. Splits taken die te groot zijn om in één sprint af te ronden op in kleine, op zichzelf waardevolle delen. Dit is een vak op zich: zie het opsplitsen van user stories.
• Omvang. Kom tot een gezamenlijke schatting in story-punten, doorgaans via planning poker, zodat de relatieve inspanning duidelijk is voordat er een toezegging wordt gedaan.
• Volgorde. Houd de takenlijst geordend, zodat de meest waardevolle en meest gereedstaande taken bovenaan staan, waar ze bij de planning als eerste worden opgepakt.

De output is geen document. Het is een doorlopende buffer van taken die klaar zijn om te worden opgepakt, doorgaans één of twee sprints vooruit ten opzichte van waar het team zich momenteel bevindt.

Frequentie: hoe vaak, hoe lang

Er is geen vaste regel, maar er is wel een verstandige standaardaanpak: één korte, terugkerende sessie als uitgangspunt, aangevuld met voortdurende kleine aanpassingen tussendoor.

Bij een sprint van twee weken houden de meeste teams halverwege de sprint één verfijningssessie, met een tijdslimiet van ongeveer een uur, en vullen ze deze ad hoc aan wanneer er vragen rijzen. Wekelijks werkt net zo goed. Het gaat niet zozeer om het exacte tijdstip als wel om de buffer: het doel is om altijd ongeveer een sprint aan gereed werk in de wachtrij te hebben staan, zodat de planning nooit de backlog hoeft te openen om vervolgens te ontdekken dat er niets is waaraan kan worden gewerkt.

Twee risico’s omkaderen de juiste omvang. Te weinig, en planning verwordt tot verfijning onder tijdsdruk: het team moet onder tijdsdruk zaken verduidelijken en opsplitsen, en verbindt zich tot werkzaamheden die het nauwelijks begrijpt. Te veel, en de verfijning zwelt uit tot een tweede planningsvergadering, waarin gedetailleerd wordt gediscussieerd over onderwerpen die wellicht nooit in een sprint terechtkomen. Dat is de verfijningskant van ceremonie-overbelasting, vergadertijd die niets oplevert. Houd u aan de richtlijn van ~10% van de capaciteit uit de Scrum Guide, dan blijft het nuttig.

Wie leidt de organisatie?

De producteigenaar is verantwoordelijk voor de backlog: de prioriteit, de bedoeling en het waarom van elk item liggen bij hem of haar. Maar het verfijnen van de backlog is een teaminspanning. De ontwikkelaars zijn degenen die de lastige vragen stellen, de complexiteit aan het licht brengen waar niemand rekening mee heeft gehouden, en de daadwerkelijke omvang bepalen. Een producteigenaar die in zijn eentje de backlog verfijnt, levert items op die voor precies één persoon glashelder zijn, maar voor alle anderen vol verrassingen zitten zodra de planning van start gaat.

De scrummaster zorgt ervoor dat de sessie binnen de vastgestelde tijdslimiet blijft en voorkomt dat deze ontaardt in een collectief ontwerpproces. Daarnaast geldt: hoe minder toeschouwers, hoe beter.

Wat „gereed” betekent: de definitie van „gereed”

Het doel van verfijning is om items gereed te maken, en „gereed” verdient een definitie, net zoals „afgerond” dat doet. Een beknopte Definitie van ‘klaar’ is de checklist waaraan een item moet voldoen voordat het team zich er tijdens de planning toe verbindt: het is begrepen, het is klein genoeg om binnen één sprint te voltooien, het heeft acceptatiecriteria, de afhankelijkheden zijn bekend en er is een schatting van gemaakt.

Verfijning en planning vormen een estafette, geen rivaliteit. Verfijning bereidt items voor, planning legt zich erop vast. Mocht de grens tussen beide binnen uw team vaag lijken, dan wordt deze duidelijk weergegeven in sprintplanning versus backlogverfijning. Voor de plaats die verfijning inneemt ten opzichte van de formele evenementen, zie Scrum-evenementen versus ceremonies.

Veelgestelde vragen

Wat is backlog-verfijning?

Het voortdurende proces waarbij productbacklog-items worden voorbereid voor uitvoering: verduidelijken wat elk item inhoudt, grote items opsplitsen, acceptatiecriteria toevoegen, de omvang ervan bepalen en ze opnieuw rangschikken op basis van prioriteit. Dit vindt gedurende de gehele sprint continu plaats, zodat het team, tegen de tijd dat een item de planningsfase bereikt, zich er zonder discussie aan kan committeren.

Is het verfijnen van de backlog een Scrum-ceremonie?

Nee. De Scrum Guide noemt het niet als een evenement. Het is een doorlopende activiteit, geen vaste vergadering, en volgens de Scrum Guide mag het niet meer dan ongeveer 10% van de capaciteit van de ontwikkelaars in beslag nemen. De meeste teams wijzen er echter een terugkerende sessie aan en behandelen het als een ceremonie, omdat het overslaan ervan de sprintplanning in chaos doet ontaarden.

Wat is het verschil tussen backlog-grooming en backlog-verfijning?

Geen. Het gaat om dezelfde activiteit. „Grooming” is de oorspronkelijke term; de Scrum-gemeenschap is overgestapt op „refinement” omdat „grooming” een ongewenste bijklank had gekregen. Veel teams gebruiken nog steeds de term „grooming”. De werkzaamheden zijn in beide gevallen identiek.

Hoe vaak dient u de backlog te verfijnen?

Doorlopend, met één korte, terugkerende sessie als anker: doorgaans één keer per week, of één keer halverwege de sprint bij een ritme van twee weken, met een tijdslimiet van ongeveer een uur. Het doel is een doorlopende buffer van gereedgestelde items, meestal één of twee sprints vooruit, zodat de planning altijd over goed materiaal beschikt om uit te putten.

Wie is verantwoordelijk voor de verfijning van de backlog?

De producteigenaar is verantwoordelijk voor de backlog en bepaalt de prioriteiten en doelstellingen, maar het verfijnen ervan is een teamactiviteit. De ontwikkelaars stellen de vragen, brengen de verborgen complexiteit aan het licht en maken een inschatting van de omvang. Wanneer een producteigenaar in zijn eentje de backlog verfijnt, leidt dit tot items die slechts voor één persoon logisch zijn en die alle anderen tijdens de planning voor verrassingen stellen.