Het doel van deze Sprint is niet om code te schrijven

Een Product Backlog een is geordende lijst van wat nodig is om het product te verbeteren waar je team aan werkt. De lijst is met een mooi woord emergent: hij wordt constant geupdate qua prioritering en aangevuld met nieuwe Product Backlog Items (PBI’s). Althans, dat is de bedoeling.

Idealiter heeft een team bij aanvang van elke Sprint Planning zo’n twee à drie Sprints aan uitgewerkte en ingeschatte ("gerefinede") PBI’s klaar staan. Dat zorgt ervoor dat tijdens de Planning gauw kan worden bepaald wat er de komende Sprint opgepakt gaat worden.

Het probleem

Mijn team worstelt al een tijd met het voldoende gevuld krijgen van de Product Backlog. Dat heeft impact op onze Planning-sessies. Deze zijn lang en moeizaam, omdat we last minute PBI’s inschatten om de komende Sprint maar gevuld te krijgen. En dat heeft op zijn beurt weer een impact op onze schattingen.

We zijn het er al langere tijd over eens dat dit een onwenselijke situatie is. Toch krijgt het team maar niet voor elkaar dit aan te pakken.

Een voorstel

Met deze situatie in het achterhoofd, stelde ik aan het eind van de afgelopen Planning voor om het op orde brengen van onze werkvoorraad tot ons Sprintdoel te benoemen.

Dat is enigszins onorthodox, want het Sprintdoel wordt doorgaans gebruikt om het team focus te kunnen geven in de keuze tussen PBI’s. Een Sprintdoel als “Feature X in productie brengen” stelt het team in staat om te zeggen: de PBI’s die dat doel dichterbij brengen hebben prioriteit ten opzichte van de PBI’s die dat niet doen.

Maar een Sprintdoel hoeft niet per se op de PBI’s op je Product- of Sprint Backlog te slaan. Het hoeft niet eens op de code te slaan die je deze Sprint oplevert. Als we aannemen dat het doel van de het Sprintdoel het aanbrengen van focus is, dan is er niets wat het team verbiedt zich te focussen op randvoorwaardelijke zaken. Bijvoorbeeld: een werkvoorraad van twee à drie Sprints realiseren tegen de tijd dat we bij de volgende Planning aanschuiven.

Het proces

Dankzij dit voorstel heb ik drie gebieden kunnen identificeren waarin het team zich kon verbeteren.

Oeverloze discussies

Het Sprintdoel stelde ons in staat om een duidelijk doelen te stellen tijdens onze Refinements: schatten, schatten, schatten.

Is een PBI niet voldoende uitgewerkt om in te schatten? Haal ’m van de agenda af en - hoppa! - door naar het volgende PBI. We hebben geen tijd om te lummelen, we zijn onze Product Backlog op orde aan het krijgen!

Onze neiging om te verzanden in oeverloze technische en functionele discussies kon worden afgekapt met een eenvoudige vraag: brengt dit gesprek ons dichter bij het behalen van het Sprintdoel?

Een stukje voorbereiding

Beter nog: in plaats van zulke discussies te laten ontstaan tijdens een Refinement, motiveerde het Sprintdoel me om vóór de aanvang van die meeting de PBI’s op de agenda door te nemen en mijn vragen en opmerkingen erbij te noteren. Dat reduceerde ruis en stroomlijnde de discussie aanzienlijk. De noodzaak om hardop te denken - met alle doodlopende paden van dien - nam enorm af door een halfuur van mijn tijd te investeren in refinement voordat de Refinement begon.

Ik kan elk team aanraden om ten minste één ontwikkelaar, naast de auteur, naar een PBI te laten kijken voordat het team als geheel zich erover buigt. Twee paar ogen zijn voldoende om de meest voor de hand liggende onduidelijkheden rondom zo’n PBI eruit te filteren.

Het gebruik van een agenda

Wat daarnaast opviel, was hoe het gebruik van een agenda in OneNote voor de Refinements ons overzicht op de Product Backlog vertroebelde. De agenda had enkele neveneffecten waar het team in de loop van de tijd een blinde vlek voor had ontwikkeld.

Zo ontmoedigt een agenda het team om de Product Backlog te gebruiken als prioriteringsmechanisme. Eén van de redenen waarom we onze werkvoorraad maar niet op orde kregen, was omdat we PBI’s inschatten die wel op de agenda van de Refinement terecht waren gekomen, maar (terecht of onterecht) een lage prioriteit hadden op de Product Backlog en dus snel weer uit ons zicht verdwenen.

Daarnaast nodigt een agenda uit om punten te agenderen die niet bijdragen aan het doel van de Refinement. Het doel van de Refinement is PBI’s refinenen. Het doel is niet, om maar iets te noemen, het bespreken van organisatorische kwesties.

Het resultaat

De focus op het op orde krijgen van onze Product Backlog heeft het team in staat gesteld focus aan te brengen op een essentiële randvoorwaarde om code te kunnen schrijven: zorgen dat je weet wat je moet gaan bouwen. Daarnaast was het een ideale aanleiding om wat ingesleten gewoonten te herzien. Oeverloze discussies, een matige voorbereiding, en het gebruik van een agenda belemmerden de efficiëntie van onze Refinements.

Deze wetenschap is de eerste stap naar verbetering. Nu is het zaak om ervoor te zorgen dat het team niet terugvalt in oude gewoontes. En mocht dat wel gebeuren, dan weten we nu in elk geval dat het Sprintdoel een effectieve manier is om die onder de aandacht te kunnen brengen.

Zijn er onwenselijke situaties waar jouw team mee worstelt? Denk je dat het Sprintdoel een goede kapstok kan bieden om die situatie te ontstijgen?

leermoment · procesverbetering · product backlog refinement · scrum · sprintdoel · sprint planning