Backlog refinement Valueminds

Backlog refinement – hoe zit dat nou precies?

De backlog refinement is een activiteit in Scrum waar veel onduidelijkheid over is. De scrum guide behandelt het niet als een meeting zoals de sprint planning of de retrospective. Die meetings hebben een duidelijke plaats aan het begin of het einde van de sprint. Maar de backlog refinement (verder: refinement) heeft niet 1 duidelijke plaats in de sprint, en wordt dus terecht wat anders behandeld.

De letterlijke tekst in de scrum guide is als volgt: Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog verfijning worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner of naar de Product Owner’s eigen beoordeling.

Het doel van de backlog refinement is dus dat het team en de product owner gezamenlijk werken aan een goede backlog. Om dit werk wat duidelijker te maken volg ik de tijdlijn van een nieuw idee naar werkende software.

Backlog refinement Valueminds

Een nieuw idee start bij een stakeholder. Misschien bij een klant die met een idee of een klacht komt, misschien bij iemand van de business die een slim idee heeft of misschien bij een developer die vanuit de techniek een suggestie heeft. Elk item dat opgepakt gaat worden door het team moet als een item op de product backlog komen en de product owner beheert deze backlog. Dus de stakeholder die een idee heeft moet in gesprek gaan met de product owner.

Dit gesprek is de eerste backlog refinement die plaatsvindt. Misschien zijn hier alleen maar de product owner en stakeholder met elkaar in gesprek. Uit dit gesprek ontstaat een helderder beeld van het idee en kan dit op de product backlog geplaatst worden. Je zou dit business refinement kunnen noemen.

Vervolgens moet dit idee met het development team besproken worden. Zij moeten helder krijgen wat er ontwikkeld moet worden en zij moeten er een inschatting van maken zodat de product owner een geïnformeerde beslissing kan nemen of zij dit item wel of niet wil laten ontwikkelen. Deze refinement kan met het gehele team gedaan worden, maar het is ook mogelijk om een eerste refinement te doen met een deel van het team. (sommigen noemen dit een pre-refinement, of prefinement). En het is zeker mogelijk om de stakeholder die met dit idee gekomen is ook uit te nodigen voor deze prefinement. Niemand kan dit idee immers beter uitleggen dan de indiener zelf. Als een idee al behoorlijk duidelijk is en de product owner er redelijk zeker van is dat dit idee snel ontwikkeld gaat worden is een refinement met het gehele team verstandig. Als het idee nog redelijk vaag is en nog even kan wachten kan het verstandig zijn om niet het gehele team in deze discussie te betrekken. Waarom de tijd van iedereen inzetten op een idee dat de discussie misschien niet overleeft?

Na de prefinement moet in ieder geval nog een ‘echte’ refinement volgen, zodat het gehele team het item begrijpt en betrokken is bij de schatting. Als het nodig is kunnen meerdere refinement sessies gehouden worden voor een item, totdat deze helemaal helder is.

Items worden tijdens de refinement geschat. Als items door de refinement discussies helder geworden zijn kunnen ze ingeschat worden en zijn ze klaar om in een volgende sprint opgepakt te worden. Het oppakken in een sprint vindt plaats in de sprint planning meeting. Als voorafgaand aan deze meeting een goede refinement plaats heeft gevonden is het eerste deel van deze meeting heel eenvoudig. We kennen onze velocity, bijvoorbeeld 30 punten, en selecteren items ter waarde van 30 punten. De product owner heeft hier een belangrijke stem in. Zij bepaalt welke items bovenaan de backlog staan en suggereert een sprint goal waar stories bij gekozen kunnen worden. Maar ook developers hebben hier een stem in. Soms is er winst te behalen door soortgelijke items als groep op te pakken. En er kan een technische reden zijn om items in een bepaalde volgorde op te pakken.

Naast het kiezen van de stories blijft dan het tweede deel over van de sprint planning, waar technische taken bedacht worden om de stories te realiseren. Dat onderwerp laat ik in deze blog verder liggen.

Het zou kunnen dat tijdens de sprint er toch nog kleine onduidelijkheden naar boven komen. Deze kunnen vaak in afstemming met de product owner nog worden verhelderd. Je zou dit de after-refinement kunnen noemen.

0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *