Backlog refinement, hoe zit dat nou precies?
Een van de activiteiten in Scrum waar het meeste onduidelijkheid over is, is de backlog refinement. Door de scrum guide wordt de backlog refinement niet behandeld als een meeting zoals bij de sprint planning of de retrospective wel gebeurt. De meetings sprint planning en de retrospective hebben een duidelijke plaats aan het begin of aan het einde van de sprint. Maar de backlog refinement (verder: refinement) heeft geen duidelijke plaats in de sprint en wordt dus wat anders behandeld.
Wat zegt de Scrum Guide?
Wanneer je de tekst letterlijk uit de scrum guide haalt, staat er het volgende:
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.
Wat we hier uit kunnen halen is dat het doel van de refinement is dat het team en de product owner gezamenlijk werken aan een goede backlog. Hieronder staat de tijdlijn van een nieuw idee naar werkende software, om dit overzichtelijker te maken.
Refinement in de tijd
Een nieuw idee start in de regel bij een stakeholder. Dit kan een klant zijn die met een idee of een klacht komt, of misschien is het wel iemand van de business die een slim idee heeft, of een developer die vanuit de techniek met een suggestie komt. De product owner beheert de backlog, waar elk item dat opgepakt gaat worden door het team op staat. Wanneer de stakeholder een idee heeft, moet deze in gesprek gaan met de product owner.
Eigenlijk is dit gesprek de eerste backlog refinement die plaatsvindt. Misschien zijn hier alleen maar de product owner en de stakeholder met elkaar in gesprek. Als het goed is, ontstaat er uit dit gesprek een helderder beeld van het idee. Dit kan dan op de product backlog geplaatst worden: je zou dit business refinement kunnen noemen.
Nadat de business refinement heeft plaatsgevonden, moet dit idee met het development team besproken worden. Zij moeten helder krijgen wat er ontwikkeld moet worden, en ze moeten ook een inschatting maken zodat de product owner een geïnformeerde beslissing kan nemen of zij dit item wel of niet wil laten ontwikkelen. Je kan deze refinement met het hele team doen, maar je kan het ook doen met een deel van het team, sommigen noemen dit een pre-refinement of prefinement. Daarnaast kan je ook de stakeholders uitnodigen voor de prefinement, zodat hij/zij het idee kan uitleggen.
In sommige gevallen is een idee al behoorlijk duidelijk en kan de product owner er bijna zeker van zijn dat dit idee zo snel mogelijk ontwikkeld gaat worden. In dat geval kan je een refinement met het hele team houden. Wanneer het idee nog vaag is, is het verstandig om dit niet met het hele team, maar met een deel van het team te bespreken. Waarom de tijd van iedereen inzetten op een idee dat de discussie misschien niet overleeft?
Wat in ieder geval nog moet gebeuren na de prefinement is een ‘echte’ refinement. Zo is het hele team betrokken bij de schatting van het item en begrijpen ze het item. Als het nodig is kunnen meerdere refinement sessies worden gehouden voor één item, totdat deze helemaal duidelijk is.
Tijdens de refinement worden items geschat. Items die door de refinement discussies helder zijn geworden, kunnen ingeschat worden en zijn klaar om in een volgende sprint opgepakt te worden. Het oppakken van deze items gebeurt in de sprint planning meeting. Wanneer je voorafgaand aan deze meeting een goede refinement hebt gehad, is het eerste deel van deze meeting heel eenvoudig. Je kent je velocity (bijvoorbeeld dertig punten), en je selecteert items ter waarde van 30 punten. De product owner heeft hier een belangrijke stem in. Zij bepaalt de prioriteit van de items en dus de volgorde van de backlog. Daarnaast suggereert zij een sprint goal waar stories bij gekozen kunnen worden. Naast de product owner hebben ook de developers hier een stem in. Soms is er winst te behalen door soortgelijke items als groep op te pakken. Of er is een technische reden om items in een bepaalde volgorde op te pakken.
Na het kiezen van de stories blijft het tweede deel van de sprint planning over, waar de technische taken worden bedacht om de stories te realiseren. Het zou kunnen dat er tijdens de sprint toch nog wat kleine onduidelijkheden naar boven komen. In afstemming met de product owner kunnen deze verhelderd worden. Dit zou je after-refinement kunnen noemen.
