Backlog Refinement, Just DO It….

cropped-Lego1600x400.png

Het continue verrijken en verfijnen van de Product backlog is enorm belangrijk binnen het Agile Scrum process. Tijdens ‘Backlog Refinement‘ (Refinement vind parallel plaats gedurende de sprints) zorgt een Scrum team ervoor dat de User stories voor de volgende sprints dusdanig goed zijn voorbereid dat deze ook uitvoerbaar zijn. Kortom, het “WAT MOETEN WE DOEN ?” is helder en WAT hebben we ervoor nodig (kennis, kunde, materiaal, etc) is ook helder.

Als zodanig voorkomt dit dat Scrum teams tijdens sprints aan onderwerpen werken die ze nog niet goed begrijpen. Daarom zit het Scrum team regelmatig samen met de Product Owner en andere belanghebbenden in zogeheten ‘backlog refinement sessies’.  Dit zijn sessies waarin de backlog wordt door gesproken, verrijkt en meer detail wordt toegevoegd. In deze refinement sessies wordt het werk voor de nabije en verdere toekomstige sprints doorgenomen en behapbaar gemaakt. 

Soms worden bij het implementeren van Backlog refinement toch wat fouten gemaakt die simpelweg voorkomen kunnen worden.

Fout 1: Niet doen.  Sprint planning meetings worden dan minder effectief omdat er veel te veel gediscussieerd wordt en veel te weinig echt gepland wordt. Continue ontwikkeling en verfijning van de product backlog is cruciaal voor Scrum. Reserveer 5-10% van de tijd van het team hiervoor. Dit wordt heel eenvoudig terug verdiend, doordat het de snelheid van een Scrum team al snel verdubbeld.

Fout 2: De juiste personen met materiekennis zitten niet aan tafel. Backlog refinement dient te worden gedaan door de juiste mensen met de juiste materiekennis aan tafel te hebben. Dit kan soms een klein gezelschap zijn. Als het hele team maar wordt geinformeerd en op de hoogte wordt gesteld en dat het hele Scrum team snapt wat de userstory inhoud en wat er gevraagd wordt.

Dus het hele Scrum team geeft de status ready aan een userstory gebaseerd op het begrijpen van de stories. In veel gevallen is er ook ruimte om al met elkaar te bespreken hoe de story het best kan worden gedaan. Echter de stakeholder en Product owner hoeven daar niet per se van op de hoogte te worden gebracht. Het delen van de informatie over het hoe is natuurlijk altijd goed, echter in de meeste gevallen is de HOE vraag minder van belang voor diegene die de functionaliteit wenst.

Fout 3: Geen separaat Ready team. Werk alsjeblieft niet met een apart ‘ready-team’. Dat zorgt alleen maar voor een verkapte waterval en het doorschuiven van verantwoordelijkheden.

Fout 4: Te veel willen bespreken en niet de tijd nemen. Een veel voorkomende fout is om veel te veel te willen bespreken tijdens refinement sessies. Men gaat het vaak al over het hoe hebben terwijl men nog niet duidelijk heeft wat het wat behelst. Voordat uberhaupt over het hoe gediscussieerd dient te worden door het Scrum team is het essentieel om het “wat” eerst helder te krijgen. Daarna is er eventueel nog ruimte voor de hoe vraag.

Ook dient het hele team of het grootste deel van het team te begrijpen wat er nu daadwerkelijk wordt gevraagd.  Het verduidelijken (refinement) gaat echter om het uitwisselen van ideeën en van elkaar leren.

TIPS:

Gebruik voor de Backlog Refinement een Definition of Ready. Dit kan in de praktijk een template zijn om te checken of een userstory voldoet aan alle voorwaarden om hem ook te kunnen inschatten. Bijvoorbeeld, snapt ieder Scrum team lid wat er bedoelt wordt. Probeer voor ongeveer maximaal 2 sprints vooruit voldoende voorraad aan user stories te hebben die de status Ready hebben. Stories die nog voor de sprint planning plaats vind ready worden gemaakt kunnen eventueel nog mee worden genomen in de volgende sprint mocht de productowner dit noodzakelijk vinden. Communicatie rondom het inplannen van nieuwe stories en de check of deze ready worden bevonden door het Scrum team is wel noodzakelijk. Stories die de status ready niet hebben kunnen niet worden meegenomen in de eerstvolgende sprint.

Backlog refinement resulteert altijd in user stories die in een sprint kunnen worden opgepakt. De refinement sessies worden niet alleen gedaan om duidelijkheid te verkrijgen. Het is tevens een zeer goed instrument om te komen tot begrips vorming en kennisuitwisseling. Doe de sessies dan ook zoveel mogelijk met het volledige Scrum team. Is dat niet mogelijk dan is het verstandig om het Scrum team goed te informeren. Nodig als dit van belang is ook de belanghebbenden uit en niet alleen de Product owner. Belanghebbenden die de functionaliteit aanvragen hebben meestal de meeste kennis om het Scrum team de meeste duidelijkheid te verschaffen.