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 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 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 werkende teams reserveren voor 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. Sla het over en de kosten verdwijnen niet. Ze verschuiven alleen naar de 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 eenheden. 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 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-points, doorgaans via planning poker, zodat de relatieve inspanning duidelijk is voordat er toezeggingen worden gedaan.
• Volgorde. Houd de werkvoorraad gesorteerd, 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 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 enkele verfijningssessie, met een tijdslimiet van ongeveer een uur, en vullen ze deze ad hoc aan naarmate 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 kant van overdaad aan formaliteiten die zich in de verfijning manifesteert: vergadertijd die niets oplevert. Houd u aan de richtlijn van de Scrum Guide van circa 10% van de capaciteit, dan blijft het nuttig.

Wie leidt het?

De producteigenaar 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. 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 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 ‘gereed’ 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, er zijn acceptatiecriteria, de afhankelijkheden zijn bekend en er is een schatting 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 afgebakend door de tegenstelling tussen sprintplanning en 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 inschatten en ze opnieuw rangschikken op basis van prioriteit. Dit vindt gedurende de gehele sprint continu plaats, 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. In de Scrum Guide wordt het niet als een evenement vermeld. 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 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 verrassingen stellen.