Als je iedere dag even een kwartiertje tot half uurtje je huis opruimt of schoonmaakt voorkom je hiermee dat al het werk zich opstapelt en je uiteindelijk je handen vol hebt om alles op orde te maken. Backlog Refinement is in die zin net als het schoonmaken van je huis. Je kunt het beter wat vaker en korter doen dan aan het einde van de maand ineens dagen lang moeten poetsen en ruimen om alles schoon te krijgen.
In deze blog neemt Serge Smit, Senior System Architect bij BPM Company, je mee in hoe Backlog Refinement in zijn werk gaat, en welke voordelen dit biedt voor de klant.

Bijhouden is de sleutel

Backlog Refinement is een continue proces. De product backlog, een lijst met wensen die je gaat realiseren, is nooit helemaal perfect. En in het uitzonderlijke geval dat hij dat wel was, dan is de situatie na een aantal weken meestal zo veranderd dat hij toch niet meer actueel is. De backlog moet dus continu worden bijgehouden, oftewel worden refined.
Het wekelijks houden van refinement sessies heeft daarnaast nog meer voordelen; het voorkomt namelijk opdroging van de backlog.  “Onlangs heb ik een project gehad waarbij heel erg de focus op de livegang lag en op eventuele nazorg. Er werd hierbij veel minder gekeken naar het refinen van nieuwe user story’s. Hierdoor ontstond er opdroging van de backlog en stond er niet voldoende werk klaar om in een volgende sprint weer op te kunnen pakken” aldus Serge. Hij pleit dan ook voor een wekelijks terugkerende refinement sessie: “Daarmee informeer je ook het team met wat eraan zit te komen. Op die manier blijft iedereen up-to-date en weet iedereen wat hem te wachten staat.”

Afhankelijkheden ontdekken

Een van de doelen van het opstellen van een Product Backlog Refinement sessie is om afhankelijkheden te identificeren. Zo kun je er achter komen dat gevraagde functionaliteiten die op je product backlog staan een grote afhankelijkheid hebben met een ander team. Dit kunnen afhankelijkheden zijn tussen verschillende User Stories doordat er bijvoorbeeld een link is met een webservice.  Een ander voorbeeld is dat het Development Team de nodige personen mist, waardoor zij op hun beurt weer afhankelijk zijn van anderen die niet in het team zitten. Door dit proces vroegtijdig te laten plaatsvinden kunnen deze zaken worden verholpen voordat zij een probleem opleveren.
Serge: “Belangrijk hierbij is dat de User Stories op het juiste moment worden gepland. Maar je betrekt elkaar ook in de realisatie bij bijvoorbeeld het testen. Je zou kunnen stellen dat op het moment dat er afhankelijkheden zijn met een ander team, de user story niet klaar is om op te pakken. Zie het als het stofzuigen van je huis. Als jij je huis aan het stofzuigen bent maar de energie leverancier levert je op dat moment geen stroom, dan is daar sprake van een afhankelijkheid. Zonder stroom kun je namelijk niet stofzuigen.”

Detaileren van User Stories

Het compleet maken van de User Stories door details aan te brengen is een belangrijk onderdeel van Backlog Refinement. De details die worden aangebracht maken het voor het Development Team bijvoorbeeld gemakkelijker in te schatten hoeveel tijd er nodig zal zijn om een User Story te voldoen. Toch hoeft niet altijd alles even specifiek te worden beschreven.
“Als ik kijk naar mijn ervaring binnen verschillende projecten verschilt dat heel erg per team. Persoonlijk vind ik het prettig als er wat ruimte is voor creativiteit. Het hoeft van mij niet allemaal heel strak in de user story beschreven te staan. Ook als ontwikkelaar is het denk ik wel prettig om wat vrijheid te hebben in de uitwerking van een user story.
Aan de andere kant is het zo dat hoe specifieker de user story is hoe minder fouten er kunnen worden gemaakt. De ‘gap’ tussen wat verwacht wordt en wat daadwerkelijk opgeleverd wordt is in dat geval dus vaak kleiner.”

Waarde creëren

Een groot voordeel van refinement is dat er een eindresultaat wordt geleverd wat tegemoetkomt aan de klantbehoefte en daarnaast functionaliteit heeft voor de klant. Het leveren van ‘waarde’ voor de klant is iets wat binnen een (agile) project altijd de hoogste prioriteit heeft.
Ik denk dat je met Backlog Refinement voor een groot gedeelte de onduidelijkheden wegneemt en dat je via dit proces dus echt kunt voldoen aan de verwachtingen van de klant. Er bestaat namelijk geen mogelijkheid meer om aannames te doen. Het opleveren van iets wat totaal niet gevraagd wordt is daardoor iets wat niet meer gebeurt”, aldus Serge.
Toch is het zo dat deze waarde niet altijd in één keer geleverd kan worden vanwege de complexiteit. Een goede Product Backlog bevat daarom heel veel kleinere User Story’s waaraan onderling prioriteit is gegeven. De User story’s die op dit moment de hoogste waarde leveren staan vanzelfsprekend bovenaan en zullen dus het eerste worden opgepakt door het team.

Tijdsbesteding

Volgens de Scrum Guide mag er maximaal 10% van de gehele tijd die aan een sprint besteed wordt, worden uitgetrokken voor Backlog Refinement. In andere woorden, in een sprint waarin fulltime gewerkt wordt, mag de Backlog Refinement maximaal 4 uur per week bedragen. Toch kan dit slechts gezien worden als een richtlijn. In de praktijk gaat hier vaak wat meer tijd in zitten.
“Het verschilt heel erg per project. Over het algemeen klopt het dat wij zo’n 10% van de tijd besteden aan het onderdeel refinement. Maar dat zijn alleen de sessies. Op de achtergrond, voordat je zo’n sessie in gaat wordt er natuurlijk ook nog tijd besteed om dingen uit te zoeken en voor te bereiden. Ik denk dat je die 10% dus uiteindelijk wel kunt verdubbelen en dat je vaak bijna 20% van de tijd met dit onderdeel bezig bent”

Conclusie

Backlog Refinement brengt een hoop voordelen met zich mee. Het voorkomt opdroging van de backlog, brengt afhankelijkheden in kaart, helpt met de tijdsplanning van het project en neemt onduidelijkheden weg. Bovendien worden door dit proces de verwachtingen van het project in een vroeg stadium duidelijk. Daarnaast kunnen User Stories worden opgedeeld in deeltaken en op basis van prioriteit worden opgepakt, zodat het Development Team zich volledig kan focussen op de komende sprint. Door refinement continue toe te passen is de kans dus vele malen groter dat het eindproduct ook daadwerkelijk ‘waarde’ oplevert voor de klant.
Dit laatste is iets waar Serge zelf het meest van geniet: “Wat ik persoonlijk het leukste vind is om echt te begrijpen wat de eindgebruiker nu vraagt. Het voelt echt prettig als je iets bouwt wat daadwerkelijk een probleem verhelpt. Vaak is het zo dat je toch wat verder weg zit van de eindgebruiker, je zit zogezegd niet naast die persoon, dus via een user story met de juiste context kun je goed inzicht krijgen in waarom het nu zo belangrijk is wat je doet. Daardoor voel ik mij heel erg betrokken en ben ik ook echt trots op het moment dat ik iets live kan zetten voor die gebruiker en daarmee zijn leven een beetje makkelijker kan maken”.

Benieuwd naar werken bij BPM Company?

Bekijk dan eens de vacatures of neem contact op met Hans Steenwijk: