Punten scoren

Door Arjen Uittenbogaard

Verhitte discussies. Het Scrumteam had een story niet af. Niet af is niet af, dus deze story droeg 0 punten bij aan de velocity van deze sprint. In de volgende sprint zou het vast afkomen, dus konden ze dan de volle 8 punten waarvoor ze ‘m hadden ingeschat incasseren. Logisch. In de gemiddelde velocity over deze twee sprints waren de punten dan correct verdisconteerd. Zo hielden ze over de lange termijn een beter zicht op wat ze echt aankunnen in een sprint.
Maar ik was tegen. Voor de volgende sprint poker je voor deze story het werk dat nog gedaan moet worden opnieuw. De punten die dát oplevert, misschien is dat er maar 1, tellen we in de volgende sprint mee voor de velocity. Rekenkundig klopt de velocity over deze twee sprints dan mogelijk niet meer. Toch vind ik het belangrijk om het zo te doen.

Als ik hoor praten over punten incasseren en verdisconteren, dan heb ik het idee dat die punten worden gezien als doel op zich. Punten die gescoord moeten worden. Werk dat verzet is, moet gewaardeerd worden. Terwijl het uiteindelijk niet gaat om hoeveel werk er verzet is, maar hoeveel resultaat dat heeft opgeleverd. De storypoints zijn alleen maar een indicatie van hoeveel werk we vooraf dachten nodig te hebben. Het zegt niks over de waarde die dat uiteindelijk oplevert. Als we een story niet af hebben, geeft dat aan dat we vooraf het werk verkeerd hebben ingeschat. Laat dat achteraf (of al tijdens de sprint!) stof ter lering zijn. Waaraan lag die onderschatting? Hoe doen we het een volgende keer iets beter? Zie die 0 punten als aansporing om deze analyse ook echt te doen.

Maar wat is er nu mis met het middelen van de waarde over de sprints waarin de story uiteindelijk gerealiseerd is? Omdat je die storypoints gebruikt voor het inplannen van werk in de komende sprint. Als daar voor die niet-affe story nog maar een beetje werk ligt, is het toch raar om daar 8 voor op te nemen? Als de velocity van het team, zeg, 15 is, zouden daardoor nog maar voor 7 punten stories kunnen worden ingepland. Terwijl iedereen aanvoelt dat er meer nieuw werk bij kan. Als die niet-affe story opnieuw gepokerd zou worden, zou het werk op bijvoorbeeld 1 punt uitkomen, met voor 14 punten ruimte voor nieuwe stories.
Met andere woorden: laten we goed het onderscheid blijven maken tussen het hebben van een nette velocity over de afgelopen sprints en een realistische planning voor de komende sprint.

Als we het hierover eens zijn én als het team al aardig volwassen is, kan ik best instemmen met een creatieve Scrum Master die vervolgens voorstelt om zowel de historische velocity op orde te houden door alle ooit gepokerde punten wel in het lopende gemiddelde op te nemen, én de niet-affe story ten behoeve van de planning van de komende sprint opnieuw te pokeren. Hoewel ik me wel afvraag of we het dan niet nodeloos ingewikkeld maken. Naarmate het team beter leert schatten, zal het steeds minder uitmaken of we die paar stories die zo nu en dan niet af zijn wel of niet meetellen in het langlopende gemiddelde. Maar bij onvolwassen teams wil ik sowieso die kant niet op. Niet zolang de velocity niet stabiel is en niet zolang de backlog niet goed gerefined is.
Het team waarmee ik in de clinch lag, had het een noch het ander. De ene sprint was de velocity 0 en de volgende 8. Daarna weer twee sprints 0 en dan weer een met 4. In zo’n geval zegt een gemiddelde helemaal niks en verdoezelt een glad gemiddelde vooral het feit dat er nog een hoop aan de schattingen moet verbeteren. En de backlog was niet goed gerefined. Bij een velocity van 8 of lager, moet je niet aankomen met stories die 8 punten of meer groot zijn. Als je dan met het verrekenen van de velocity aan de gang gaat zoals dit team wilde, veeg je onder de tafel dat er veel meer werk gemaakt moet worden van de refinement. Met zo’n glad gemiddelde lijkt het niet meer uit te maken hoeveel sprints je doet over het realiseren van een story. Op zo’n manier helpt het gemiddelde helemaal niet meer bij het goed inplannen en snel realiseren van waardevol werk.

Na het gesprek met dit team, ben ik natuurlijk ook weer eens gaan zoeken wat wat er zoal over dit onderwerp is geschreven. Zo stuitte ik op de school die zegt: stories die niet af zijn, gaan gewoon terug op de backlog. De PO kan dan besluiten of hij het nog steeds de moeite waard vind om capaciteit aan die story te spenderen. Als (als) het ding dan op enig moment weer bovenaan komt te staan, wordt het dus vanzelf weer gepokerd door het team. En daarmee is de hele puntendiscussie van de baan.

Arjen Uittenbogaard

Arjen is verhalenverteller. Een training van hem is een ervaring die je niet licht vergeet. Hij is ook regisseur van improvisatietoneel. Dat vindt hij een mooie metafoor voor zijn werk in het coachen van teams en individuen in organisaties die meer agile willen worden. Want dat is zijn expertise: agile werken. Daar heeft hij al twintig jaar ervaring mee en daar is hij goed in. Zijn hart gaat uit naar de menselijke kant van het werk, naar de communicatie en de samenwerking. Daarbij weet hij alles van complexe adaptieve systemen: omgevingen waarin niets is wat het lijkt, waar best practices je op het verkeerde been kunnen zetten en waar je steeds zult moeten experimenteren en leren. Ook heeft hij nog steeds lol van zijn achtergrond in object georiënteerde softwareontwikkeling: hij mag ontwikkelaars graag uitdagen op hun ontwerpen en de toepassing van design patterns daarin.

06 - 59 443 440

Andere posts

Klik hier