Veel Scrumteams gebruiken de reeks van Fibonacci voor het inschatten van de omvang van werkzaamheden. Dit maakt plannen in scrum mogelijk.
Waarvoor gebruik je dit model?
- Als Product Owner wil ik richting stakeholders kunnen communiceren wanneer releases plaatsvinden, Zodat de verwachtingen realistisch blijven.
- Als manager wil ik weten hoeveel werk een Scrumteam wegwerkt en nog op de Backlog heeft, Zodat (1) ik weet wanneer men iets oplevert en (2) ik beslissingen rondom resources kan nemen.
Uitleg bij het plannen in scrum
Uit traditionele projectplanningen kun je precies aflezen wat wanneer af is binnen een project, helaas blijken deze plannen in de praktijk niet altijd even accuraat. Onverwachte veranderingen of tegenslagen hebben tot gevolg dat de projectplanning moet worden aangepast. Hoe zit dit met het plannen in Scrum? Ook binnen Scrum kun je een planning maken. Gelukkig maar, want klanten en andere stakeholders hebben het recht om te weten wanneer zij resultaat kunnen verwachten. Voordat het mogelijk is om een planning te maken zal het team een inschatting moeten maken van de hoeveelheid werk op de Product Backlog. Vaak wordt hiervoor de Story Point-methode gebruikt.
Story Points geven de moeite weer die het team moet verzetten om een User Story te realiseren. Neem als voorbeeld onderstaande stad. Als de hoogste toren 10 Story Points (oftewel 10 ‘moeite’) kost om te realiseren, dan kost een gebouw dat half zo hoog is 5 Story Points. Het betreft hier dus een relatieve eenheid waarbij men werk ten opzichte van elkaar inschat.
Waarom gebruiken teams Story Points?
De hoofdreden om Story Points te gebruiken is om weg te blijven van discussies over tijd. Een ervaren marketeer zal bijvoorbeeld veel sneller een brochure opmaken dan een marketeer die net begint met werken. Hoewel de ervaren marketeer en de jonge marketeer geen overeenstemming zullen vinden in de hoeveelheid tijd die in de brochure gestoken moet worden, zullen zij dat wel vinden wanneer zij Story Points gebruiken en de hoeveelheid werk relateren aan andere werkzaamheden.
Reeks van Fibonacci
Op deze manier ga je het juiste gesprek aan en komt er verdieping in het werk en de bijbehorende taken, in plaats van een zinloze discussie over tijd te voeren. Om het nog een stapje ingewikkelder te maken gebruikt men vaak de reeks van Fibonacci om User Stories in te schatten. In deze reeks vormen twee aan elkaar grenzende cijfers samen steeds het volgende cijfer:
0, 1, 1, 2, 3, 5, 8, 13, 21, enz. (1 + 1 = 2, 2 + 1 = 3, 2 + 3 = 5, 3 + 5 = 8, enz.)
De reeks van Fibonacci vind je veel terug in de natuur. Zo volgt de vermenigvuldiging van een populatie konijnen de reeks, maar ook het aantal vertakkingen van een boom. Bovendien zul je in de afbeelding waarmee dit artikel begon een schelp of slakkenhuis hebben herkend. Ook hiervoor is Fibonacci de basis.
Fibonacci helpt bij plannen in scrum
Deze reeks is geschikt voor het inschatten van werkzaamheden omdat de sprongen in de reeks steeds groter worden. En waarom zijn deze steeds grotere sprongen in de reeks handig? Omdat iedereen het verschil tussen 1 en 2 Story Points kan opmerken. Het is daarom zinvol om dat onderscheid te maken. De ene is namelijk twee keer zoveel moeite als de andere. Maar het verschil tussen 13 of 14 Story Points daarentegen is zeer lastig te bepalen. Om die reden worden de sprongen in de reeks steeds groter, dan hoeven we niet te discussiëren over of een User Story een waarde van 13 of 14 moet krijgen. Het volgen van de reeks van Fibonacci als mogelijke waarden voor Story Points zorgt er in de praktijk voor dat (1) teamleden het met elkaar eens zijn en (2) er weinig tijd aan planning besteed hoeft te worden, zodat er meer tijd overblijft voor het verzetten van waardevol werk voor klanten.
Het gebruik van Story Points en het gebruik van de reeks van Fibonacci zijn bij Scrum niet verplicht, maar beide methoden worden wel gezien als best practices.
Story Points: Twee werkvormen
Swimlane Sizing
De simpelste toepassing van Story Points en Fibonacci is Swimlane Sizing.
- Hang een flip-overvel aan de muur en teken een aantal banen, met de nummers van Fibonacci boven in elke baan.
- Laat het team vervolgens User Stories plakken in de baan die het corresponderende aantal Story Points weergeeft. Laat dit een zelforganiserend proces zijn waarin teamleden met elkaar het gesprek aangaan over hoeveel moeite bepaalde onderdelen van het project kosten.
Let op! Deze manier van inschatten van User Stories gaat over het algemeen vrij snel, maar is minder grondig dan de volgende werkvorm. Houd in de gaten of iedereen een volledig begrip heeft van al het werk.
Planning Poker
Een andere werkvorm is Planning Poker. Iedereen krijgt een set kaarten met daarop de nummers gebaseerd op de reeks van Fibonacci. Neem vervolgens per User Story de volgende stappen:
- De Product Owner licht een User Story toe.
- Iedere Developer kiest een kaart en legt deze dicht op tafel.
- Als iedereen heeft gekozen, draait men de kaarten om. De personen die de minste en de meeste Story Points hebben toegekend aan een User Story, lichten hun keuze toe. Vaak blijkt dat een User Story onvoldoende duidelijk is omschreven door de Product Owner, of door een teamlid onvoldoende begrepen wordt. De Product Owner geeft dan een toelichting en past zo nodig de User Story aan.
- Iedere Developer kiest opnieuw een kaart. Wanneer iedereen gekozen heeft, worden de kaarten weer omgedraaid.
- Herhaal dit proces totdat er voldoende overeenstemming is over het aantal Story Points.
Burndown Chart
Als al het werk is ingeschat, kan de Product Owner een zogenaamde Burndown Chart maken. Deze grafiek geeft de resterende hoeveelheid werk weer en gebruikt de Product Owner voor planning binnen Scrum. Burndown Charts geven betere inschattingen van opleveringen dan de ouderwetse balkenplanning. De reden hiervoor is dat je met het plannen in scrum uitgaat van daadwerkelijk gerealiseerd werk.
Bron: Het Scrum modellenboek
Door: Rik van der Wardt
