Scrum: de fijne kneepjes van backlog refinement

Backlog refinement  – het actualiseren van de backlog  – is net als de afwas. Je kan het beter wat vaker en korter doen, dan je na twee dagen door een aangekoekte berg vaat heenwerken. Hier enkele tips om effectief met backlog refinement om te gaan.

Zeg niet grooming, maar zeg refinement

We hadden het voorheen over backlog grooming. Maar sinds ‘grooming’ een vies woord is geworden hebben we het liever over refinement. Dat is ook nog eens gebruikelijker en makkelijker. Als je dus over backlog grooming leest  –  bijvoorbeeld in het scrumboek ‘Get Agile!‘ (aff.)  – dan weet je dat dit hetzelfde is.

Refinement bestaat uit drie activiteiten

Een product backlog, de lijst met wensen die je gaat realiseren, is nooit perfect. En als hij dat was, dan is de situatie na twee weken meestal zo veranderd dat hij toch niet meer actueel is. De backlog moet je dus continu bijhouden. Bijhouden bestaat hierbij uit drie belangrijke onderdelen:

1. Scherp houden wat je precies hebt aan het eind van het project. Dit kan op twee manieren. Mijn favoriete manier is om alle wensen grofweg in te delen in sprints. Je weet hoeveel sprints er zijn in het budget, dus je ontdekt al gauw welke wensen er niet bij passen omdat ze niet ingedeeld kunnen worden. Je kan als tweede manier ook een grove schatting doen met de product owner en Scrum master van het aantal story points dat je nodig zult hebben. Een optelsom laat dan zien hoe ver je komt. Omdat de inschatting grof is, stapel je hierbij fout op fout. Het eindresultaat is daarom minder accuraat.
2. Nieuwe wensen inweven in de product backlog. Het mooie van Scrum is dat het zo goed met nieuwe wensen en voortschrijdend inzicht kan omgaan. De backlog refinement is het moment waarop nieuwe wensen op de backlog komen. De wensen krijgen dan een mooie beschrijving in de vorm van een user story en een bepaalde prioriteit of waarde. Het team heeft de mogelijkheid om vragen te stellen en een eerste grove inschatting te maken.
3. Zorgen dat er genoeg stories ‘ready for sprint zijn’ vóór de volgende sprint er is. Je controleert of de story voldoet aan de I.N.V.E.S.T.-criteria. Zijn er nog extra wensen vanuit de organisatie? Is het duidelijk hoe de data eruit zien waar eventueel op gekoppeld gaat worden? Is er tekst en beeld beschikbaar? Zijn er bijzondere randvoorwaarden? Weet iedereen in het team wat zij moet doen?

Light, basic of deluxe?

Het is slim om tijdens de refinement alvast te bedenken wat een story simpel of deluxe maakt. Wat is minimaal? Wat zou het juist supermooi maken? Zo denk je na over verschillende oplossingen. Het helpt je ook om sterke keuzes te maken. Een product waarin een paar essentiële features heel bijzonder zijn uitgevoerd, en de rest gewoontjes, doet het namelijk veel beter dan een product waarin alles gemiddeld is.

Definition of ready

Omdat de INVEST-criteria nogal abstract zijn, kan het nuttig zijn om daar een concrete vertaling van te maken voor het project waar je mee bezig bent. Dat noemen we de definition of ready: een lijst met criteria die door het hele team begrepen wordt. Een checklist om te controleren of een story klaar is om de sprint in te gaan. Het helpt de product owner om haar werk te structureren. Zijn de juiste stakeholders geraadpleegd? Is het boodschappenlijstje van de developer afgewerkt? De definition of ready werk je uiteraard bij in elke retrospective.

De product owner is eigenaar van de backlog

Het hele team is er bij betrokken, maar de product owner en de Scrum master zijn verantwoordelijk — – de product owner beslist en de Scrum master zorgt dat haar team door kan werken door de product owner op prangende onduidelijkheden te wijzen.

Plan spikes

Het kan zo zijn dat er zo veel onbekende factoren zijn rondom een story, dat die story niet in te schatten is. Je wilt dan even gericht tijd investeren om het een en ander uit te zoeken. Het is Scrum, dus zo’n onderzoek gaan we timeboxen en zichtbaar maken. Het onderzoek komt op de backlog en krijgt een vaste hoeveelheid tijd toegewezen. In Scrum noemen we dit een spike. Tijdens een spike maak je een experimentele oplossing binnen een vaste tijd. Misschien is dat een schets, een prototype, of een stuk ruwe code. Spikes zijn bedoeld om te helpen met schattingen. Het is helemaal niet erg om de resultaten niet in productie te nemen.

Dagelijks en kort

Oerscrummers Ken Schwaber en Jeff Sutherland adviseren om 5 procent van je tijd te spenderen aan backlog refinement. Bij de gemiddelde sprint van 3 weken, 3 dagen per week, komt dat neer op 3,5 uur per teamlid. Misschien is dat zelfs wat aan de lage kant, zeker voor de product owner, die soms wel 50 procent van haar tijd daarmee bezig is. Mijn ervaring is dat bij bijna elke retrospective terugkomt dat de stories duidelijker gedefinieerd hadden moeten zijn. Dus het antwoord op de vraag hoe vaak/hoe lang luidt meestal: meer dan je nu doet. Het liefst dagelijks even kort. Of anders wekelijks en wat langer.

Haal je team niet uit de flow

Doe het in elk geval niet direct na een stand-up, of wanneer je voelt dat het team in de flow is en niet gestoord mag worden. Vind een moment waarin teamleden enkele minuten tijd hebben. Ik heb zelf een voorkeur voor de middag. Als je dan even je gedachten verzet van waar je mee bezig was naar wat nog komt, helpt het je uit de middagdip en kun je daarna weer heel gefocust aan de slag.

Meer van dit?

Volgende keer heb ik het over hoe je design en development combineert in Scrum. Andere prangende vragen over scrum? Tweet me (@antonvh) en dan schrijf ik er een stukje over.

Happy scrumming!

Dit artikel is het tweede deel in een serie over Scrum. Lees hier het eerste deel: ‘6 redenen om niet te scrummen’.