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

Het verfijnen van de backlog — nog steeds vaak ‘grooming’ genoemd — is het doorlopende proces waarbij productbacklog-items worden voorbereid vóór de sprint waarin ze zullen worden ontwikkeld: 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 gebeurtenissen 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 dus gelijk: het is geen ceremonie.

En toch is de gids van Asana over agile ceremonies getiteld „4 evenementen + backlogverfijning”, en de meeste werkende teams reserveren voor verfijning een vaste plek 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 slechts een titel en een vage hoop — omgezet in bruikbare elementen. In de praktijk bestaat dit uit vier stappen, die continu worden doorlopen:

• Verduidelijk. Maak van „de onboarding verbeteren” een doelstelling met een duidelijke intentie en acceptatiecriteria waaraan het team kan toetsen of dit is gelukt.
• Opsplitsen. Splits taken die te groot zijn om in één sprint af te ronden op in kleine, op zichzelf waardevolle delen. Dit is een kunst op zich — zie het opsplitsen van user stories.
• Omvang. Kom tot een gezamenlijke schatting in story-points, doorgaans via planning poker, zodat de relatieve inspanning duidelijk is voordat er toezeggingen worden gedaan.
• Volgorde. Houd de backlog gesorteerd, zodat de meest waardevolle en meest gereedstaande taken bovenaan staan, waar ze bij de planning als eerste aan bod komen.

De output is geen document. Het is een doorlopende buffer van items die klaar zijn om te worden opgehaald — doorgaans een 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 klaar 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.

Tussen twee uitkomsten ligt de juiste balans. Is de omvang te klein, dan verandert de planning in verfijning onder tijdsdruk — het team moet onder tijdsdruk zaken verduidelijken en opsplitsen, en zich vastleggen op werkzaamheden die het nauwelijks begrijpt. Te veel, en de verfijning zwelt uit tot een tweede planningsvergadering, waarin gedetailleerd wordt gediscussieerd over punten die wellicht nooit in een sprint terechtkomen. Houd u aan de richtlijn van de Scrum Guide van circa 10% van de capaciteit, dan blijft het nuttig.

Wie leidt het?

De productowner is verantwoordelijk voor de backlog — de prioriteit, het doel en het waarom van elk item vallen onder zijn of haar bevoegdheid. Maar het verfijnen van de backlog is een teaminspanning. Het zijn de ontwikkelaars die de lastige vragen stellen, de complexiteit aan het licht brengen waar niemand rekening mee heeft gehouden, en de daadwerkelijke omvang van de taken bepalen. Een productverantwoordelijke 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 „klaar” betekent: de definitie van „klaar”

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 af te ronden, er zijn acceptatiecriteria, de afhankelijkheden zijn bekend en er is een schatting gemaakt.

Verfijning en planning vormen een estafette, geen rivaliteit — verfijning maakt items gereed, planning legt zich erop vast. Mocht de grens tussen beide binnen uw team vaag lijken, dan wordt deze in sprintplanning versus backlogverfijning duidelijk in kaart gebracht. 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 inschatten en ze opnieuw rangschikken op basis van prioriteit. Dit vindt continu plaats gedurende de sprint, zodat het team zich, tegen de tijd dat een item de planningsfase bereikt, 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. Maar de meeste teams wijzen er 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”. Het werk is in beide gevallen identiek.

Hoe vaak dient u de backlog te verfijnen?

Doorlopend, met één korte, terugkerende sessie als ankerpunt — doorgaans één keer per week, of één keer halverwege een 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 voor één persoon logisch zijn, maar die alle anderen tijdens de planning voor een verrassing stellen.