Ik heb met heel wat Scrum teams samengewerkt. Bij ieder team gebeurde het wel eens bij het inschatten: “Dat is 1 story punt omdat het zo weinig werk is.” Voor de lezers die tot hier zijn gekomen en zich nu al afvragen wat die story punten eigenlijk zijn, even een korte introductie.
Waarom we geen uren schatten
Vaak hebben teams die beginnen met Scrum de neiging om het werk in te schatten op basis van tijd. Er wordt dus naar een bepaalde taak gekeken en ingeschat hoeveel tijd de uitvoer gaat kosten. Het grote probleem is, dat we super slecht zijn bij het maken van inschattingen op basis van tijd.
Zeker naarmate de complexiteit en onvoorspelbaarheid toenomen, wordt een schatting maken op tijd steeds lastiger.
“Bij ons is dat anders! Onze tijdinschattingen kloppen wel bijna altijd!”
Om heel eerlijk te zijn is mijn eerste reactie daarop iets in de trant van: “bin there, done that”. Niet om vervelend over te komen, maar omdat ik dat argument heel vaak gehoord heb en heel vaak al bij de eerste planning heb zien sneuvelen. Niet voor niets lopen zo ontzettend veel projecten uit. Zowel op tijd als op budget.
Geloof het of niet, we zijn gewoon super slecht in het maken van schattingen op basis van tijd!
SOPHIA Ontdek hoe je de aanpak van SOPHIA ook in jouw organisatie kunt doorvoeren om wendbaar en inclusief te organiseren. Download gratis de eerste 2 hoofdstukken van dit nieuwste boek.
Download de eerste 2 hoofdstukken
De wijsheid van wendbare organisaties
Story punten zeggen niets over tijd
De grootste uitdaging is dan ook om beginnende Scrum teams te leren de tijdsinschatting los te laten. En ook hier kan ik uit ervaring zeggen, dat dit lastiger is dan het lijkt. Wanneer het team eenmaal gestart is ontstaat toch al weer snel een connectie tussen punten en tijd. Immers deden we de laatste keer 8 uur over die story van 5 punten. Een halve dat zou dan toch ergens rond de 2 of 3 punten moeten liggen?
Deze connectie met tijd wordt natuurlijk ook we gevoed door de term ‘velocity’. Binnen Scrum een manier om in te schatten hoeveel punten er in een sprint kunnen. Immers, als we in een sprint van 2 weken ongeveer 40 punten afronden, dan doen we toch 5 punten per dag?
Het probleem is dat het gaat om een gemiddelde. Die 40 punten staan gelijk aan misschien wel 15 stories. Stories van 13 punten en stories van 1 punt. Tijdens de sprint kan het zomaar zijn dat een story van 13 punten enorm meeviel en een story van 1 punt enorm tegen. Ik heb ooit eens in een team gezeten wat een story van 2 punten niet afgerond kreeg in een sprint, terwijl ze normaal ruim 50 punten per sprint wisten af te ronden!
De opbouw van een story punt
Nu vraag je misschien af hoe die punten dan tot stand komen. Als ze niet op tijd ingeschat worden, waarop dan wel? Hiervoor moeten we kijken naar wat mensen, in dit geval professionals in hun vakgebied, wel goed in kunnen schatten.
Zoals we gezien hebben zijn dat niet de uren, maar is dat iets anders. Het gaat hier om complexiteit, risico én tijdsinspanning. Dit noemen we ook wel de ‘effort’. Nu denk je misschien meteen dat mijn eerste verhaal wat raar is, nu er toch over tijdsinspanning gesproken wordt. Die tijdsinspanning wordt in dit geval zwaar beïnvloed door de complexiteit en het risico dat we lopen bij de uitvoering van het werk. Laten we ze alle 3 eens bekijken:
Complexiteit
De complexiteit gaat over het werk zelf. Wanneer we iets doen kan dat werk zijn dat relatief simpel is. Denk aan een kleine aanpassing in een bestaande functie of handleiding. Dit is niet heel complex om te doen. Dan krijgt complexiteit dus een lage score.
Het kan ook zijn dat er een nieuw algoritme geschreven moet worden of een hele nieuwe functie ontwikkeld. In dat geval neemt de complexiteit toe, en daarmee ook de score.
Risico
Ook het risico is een bepalende factor. Wanneer een aanpassing ervoor kan zorgen dat het hele bedrijf plat ligt of een hoge impact heeft op de klantervaring, dan is er een groot risico. Als het immers mis gaat, gaat dat een hoop geld kosten.
Natuurlijk hoeft dat niet zo te zijn. De aanpassing van een tekst op de website heeft bijvoorbeeld een laag risico. Als er dan echt iets fout gaat is het ergste dat er kan gebeuren dat de tekst nog een keer aangepast moet worden.
Tijdsinspanning
De tijdsinspanning bepaald een deel het uiteindelijke aantal story punten. Hiervoor reken je niet met uren maar met een schaal. Bijvoorbeeld laag, gemiddeld, hoog. Dit zorgt ervoor dat je weg blijft bij het inschatten op tijd en dat belangrijker laat worden dan de complexiteit en het risico.
Persoonlijk probeer ik tijdsinspanning zoveel mogelijk buiten de planning te houden. Dit omdat er dan zichtbaar wordt welke dingen veel tijd kosten maar weinig complexiteit en risico kennen. Vaak zijn dat dingen die we kunnen verbeteren. Iets heel eenvoudigs waar je de hele sprint mee bezig bent, kan waarschijnlijk worden geautomatiseerd. Herinner je het voorbeeld van de 2 punten die niet afkwamen? Dat is ons daarna niet meer gebeurt omdat we het zover hebben kunnen automatiseren dat het de volgende keer niet meer 2 weken tijd kost, maar slechts een uurtje!
Het gaat om de verhouding
Story punten = complexiteit, risico en tijdsinspanning. Eigenlijk een heel eenvoudige formule om toe te passen. Toch komt dan vaak de vraag wat complexiteit en risico dan eigenlijk zijn. En die tijdsinspanning, laag, middel of hoog ten opzichte van wat? We gaan immers niet meer in uren rekenen!
Deze variabelen berekenen we op basis van een referentie story. Dit is een story waarvan iedereen precies weet wat de bedoeling is. Het risico en de complexiteit zijn laag en het werk dat gedaan moet worden is overzichtelijk en helder.
Deze story geven we vervolgens punten. Gewoon door ze samen af te spreken.
Voor de inschatting van de punten wordt vaak de Fibonacci reeks gebruikt: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, enz. Het is vaak handig om voor de referentie story uit te gaan van 5 of 8 punten. De volgende story die je echt gaat inschatten kun je dan hoger of lager inschatten.
Stel: je hebt de referentie story 5 punten gegeven. Tijdens het inschatten van de volgende story vraagt het team zich het volgende af:
- Is deze story: minder complex, net zo complex of complexer dan de referentie story?
- Als deze minder complex is, hoeveel minder? De helft? Helemaal niet complex?
- Als deze complexer is, hoeveel complexer? Eens zo complex? Super complex?
- Is deze story: minder risicovol, net zo risicovol of risicovoller dan de referentie story?
- Als deze minder risicovol is, hoeveel minder? De helft? Helemaal niet risicovol?
- Als deze risicovoller is, hoeveel risicovoller? Eens zo risicovol? Super risicovol?
- Is voor deze story: minder tijd nodig, net zoveel tijd nodig of meer tijd nodig dan de referentie story?
- Als er minder tijd nodig is, hoeveel minder? De helft? Praktisch geen tijd?
- Als er meer tijd nodig is, hoeveel meer tijd? Eens zoveel tijd?
Het valt je misschien op dat de uitkomsten waar ik om vraag niet absoluut zijn. Dat komt omdat we daar de getallen van de Fibonacci reeks voor gaan gebruiken. Stel de story is complexer dan de referentie story, maar niet ‘eens zo complex’. De referentie story had 5 punten dus komen we uit op 8.
Het risico van de nieuwe story is een stuk groter. Deze schatten we in op 13. Qua tijdsinspanning komen we een beetje vergelijkbaar uit.
We kunnen nu de geschatte waarden bij elkaar nemen: complexiteit: 8, risico: 13, tijdsinspanning: 5 en tot een “gemiddelde” van 8 punten komen.
De story punten van teams zijn niet te vergelijken
Een heel belangrijk punt dat ik zeker nog wil maken, is dat story punten niet vergeleken kunnen worden tussen verschillende teams. Ieder team schat op een eigen manier, heeft een eigen expertise en doet vaak ook ander werk.
Wanneer je denkt dat het bekijken van story punten inzicht geeft over de productiviteit van de verschillende teams, kom je bedrogen uit. Dit is eenvoudigweg niet het geval. Het enige wat je van buitenaf kunt zien is - en ook dat is maar gedeeltelijk - de volwassenheid van het team. Daarbij kijk je niet naar de story punten zelf, maar naar het aantal punten dat een team beloofd op te leveren voor een sprint en het aantal daadwerkelijk opgeleverde punten. Als die twee bij elkaar liggen betekent dit dat het team goed inzicht heeft over het werk dat ze doen.
Het gesprek is van belang
Houd er rekening mee dat het aantal story punten een hulpmiddel is voor het team. Het gebruik voorafgaand aan een sprint planning zorgt ervoor dat het team weet wat ze wel en wat ze niet kunnen oppakken.
Uiteindelijk, vind ik, is het gesprek tijdens het inschatten het belangrijkste. Wanneer teamleden ver uit elkaar liggen met de punten, is dat vaak een indicatie dat de story nog onduidelijkheden bevat. Hoe dichter de punten bij elkaar liggen, hoe duidelijker de story is.
Probeer daarom ook niet het proces te versnellen door naar 1 inschatting het gemiddelde te pakken. Stel je voor dat de teamleden een 1 opgooien maar dat de specialist in het team een 13 opgooit. Met een team van 8 mensen kom je dan uit op gemiddeld 3 punten (afgerond). Wanneer de specialist gelijk had - wat natuurlijk aannemelijk is - zou dit een onderschatting betekenen van een ruime factor 4. Met andere woorden, de uiteindelijke effort is 4 keer groter dan ingeschat.
Ga daarom altijd het gesprek aan. Waarom denkt die ene persoon dat het 13 is en de rest 1? Waar zit dat verschil? Soms zie je dat het een verschil in opvatting is en eindigt het aantal punten meer in het midden. Soms merk je dat het een onbegrip is en verschuift het uiteindelijke aantal punten naar de uiterste.
Ter afsluiting
Bij veel teams die beginnen met Scrum voelt deze manier van inschatten nogal onwennig. En niet alleen bij de teams! Ook leidinggevenden hebben vaak het idee dat het loslaten van tijd zorgt voor minder controle en overzicht. Ook hier spreek ik uit ervaring wanneer ik zeg dat het schatten met punten een akelig accurate manier van schatten is.
Ik ben ooit eens Scrum Master geweest van een team dat door het management gevraagd werd een tijdsinschatting te geven. Ze gaven aan in 6 maanden klaar te zijn. Het team had al aardig wat sprints erop zitten en het aantal punten wat ze per sprint afronden was stabiel.
Samen met het team heb ik daarom de openstaande taken grof ingeschat. Hierbij zijn we niet steeds het gesprek aan gegaan, maar hebben we in stilte de punten gegeven. Op basis van die ‘hoog over punten’, hebben we vervolgens een nieuwe schatting gegeven. We zouden niet in 6 maanden maar in 17 maanden klaar zijn.
We bleken er met die 17 maanden slechts 5 dagen naast te zitten! Ineens is het niet meer zo verbazend dat projecten die op tijd zijn ingeschat vaak uitlopen!