Storypoints voor dummies

Stel je een koning voor die een maateenheid heeft vastgesteld op basis van de grootte van zijn voet. Dat werkt prima, echter die koning kan niet voorkomen dat andere koningen hun eigen voeten gebruiken om de meetnormen in hun koninkrijken vast te stellen. In het verleden hadden de Chinezen hun eigen maateenheid; deze was bijna tien procent groter dan de Amerikaanse versie, en de gestandaardiseerde eenheid in Hong Kong was zelfs nog groter! Wie had dat gedacht? Handelaren die tussen koninkrijken reisden, bespraken allemaal dezelfde items, maar ze hebben allemaal een ander beeld van wat de grootte van een voet eigenlijk was.

Het waren de homo sapiens die dingen begonnen te meten. Hun maateenheden waren vrij eenvoudig: de afstand tussen thuis en de grot van een vriendin, kon worden gemeten in het aantal dagen dat het duurde om daarheen te lopen; langere afstanden werden gemeten in maancycli; gewichten gemeten naar wat een man zou kunnen dragen; enzovoort. Het werkte… maar niet zo goed. Deze methoden waren niet erg precies, maar ze dienden hun doel. Het heeft de mensheid veel tijd gekost voor men bepaalde hoe afstand en tijd uitgedrukt kon worden op een gestandaardiseerde manieren.

Waarom niet gewoon schatten in uren?

Stel je een paar softwareontwikkelaars voor. Als je ontwikkelaar één zou vragen hoeveel tijd het zou kosten om een ​​bepaalde functie te ontwikkelen, zou hij schatten op basis van zijn ervaring en kennis. Laten we zeggen dat hij denkt dat de taak hem acht uur zou kosten. Ontwikkelaar twee, die precies hetzelfde doet, antwoordt dat dezelfde taak hem slechts vijf uur kost. Wat als ze allebei gelijk hebben? Wat is er net gebeurd? Wel, net als de homo sapiens die afstanden uitgedruktten in dagen van wandelen – een nogal onnauwkeurige methode – moeten we een paar variabelen scheiden om een ​​meer precisie te bereiken.

De ontwikkelaars schatten de omvang en de complexiteit van de opdracht, evenals de inspanning die vereist is om het te leveren. De berekeningen hielden echter niet op; ze voorspelden ook de snelheid waarmee ze zouden kunnen werken. Beide ontwikkelaars veronderstelden ten onrechte dat ze de volledige controle konden behouden over hoe snel ze aan het project zouden kunnen werken.

Tenzij ze elk een functionerende glazen bol hebben, moeten voorspellingen zoals deze voorzichtig worden gedaan. De snelheid waarmee iemand kan werken is sterk afhankelijk van vele variabelen, zoals de omgeving waarin men werkt, de volwassenheid van zijn team en de kwaliteit van de beschrijving van de te ontwikkelen functie. Dus, wat als we de omvang van een taak konden schatten zonder te voorspellingen te doen die een magische bol vereisen? Als we “snelheid” uit de vergelijking halen, krijgen een hogere mate van precisie. Storypoints laten ons toe om dat te doen, door de grootte van een taak en niets anders uit te drukken. Hoe doen ze dit? De algemene gedachte achter storypoints is dat ze de grootte van een taak bepalen, onafhankelijk van de persoon die het eigenlijke werk gaat doen.

Eén van de uitdagingen met userstories is dat er geen exacte definitie is van hoe groot een taak moet zijn om in één enkele storypoint te passen. Geen enkel apparaat kan de grootte van een bepaalde taak meten; dus, net als de vroege homo sapiens, moeten we tot een gemeenschappelijk begrip komen van wat een enkel storypoint vertegenwoordigt. De koning in ons verhaal gebruikte zijn eigen voet als referentie; dit werkte prima, zolang hij de meting niet buiten zijn eigen koninkrijk probeerde te gebruiken.

De standaard instellen

Het is gebruikelijk voor alle leden van een team om een ​​kleine taak als referentie te gebruiken om overeenstemming te bereiken over de waarde van storypoints. De teamlede kiezen de taak die met het grootste vertrouwen geschat kan worden en kennen een storypoint-waarde toe waar ze het allemaal mee eens zijn. De waarde van de inschatting is minder belangrijk dan het niveau van vertrouwen dat iemand in de waarde heeft. Nadat deze waarde is ingesteld, kan de grootte van elke volgende taak worden vergeleken met de referentietaak, waardoor het min of meer mogelijk is om het gewicht of de omvang van een bepaalde taak te schatten. Over het algemeen gebruikt een groep mensen de macht van twee of heeft een schaal zoals 1, 2, 5, 8, 20, …, bij het schatten. Hoe groter de schatting van een taak, hoe minder zeker en dus nauwkeurig deze is. Door gebruik te maken van de Fibonacci-reeks kunnen teams deze onzekerheid herkennen en opzettelijk een gebrek aan precisie creëren. Het is meestal logisch om deze grotere taken in meerdere kleinere op te splitsen, zodat de schatting voor elke afzonderlijke taak betrouwbaarder wordt. Hoe meer we taken splitsen, hoe meer de totale schatting naar het oneindige neigt vanwege afrondingsfouten en angstfactoren die we vermenigvuldigen in gedetailleerde schattingen. Om meer vertrouwen te krijgen in de nauwkeurigheid van de waarde van de storypoints, kunnen technieken zoals het planning-poker of scrum-poker worden gebruikt, waarbij voorkomen wordt dat leden van een groep elkaar beïnvloeden. Oké, maar hoe zit het met het budget?
De realiteit is dat storypoints nutteloos zijn als het gaat om budgetteren. Als je een manier kunt bedenken om te meten hoe lang het duurt om een ​​enkele storypoint volledig te leveren, dan zou het mogelijk moeten zijn meer te weten te komen over je project, zoals de totale kosten van het project of de verwachte leverdatum. De toegewezen storypoints gedeeld door de tijd die het kost om een taak op te leveren, is wat we velocity noemen. Velocity is een waarde die alleen kan worden ontdekt door de tijd te meten die een team nodig heeft om de gevraagde output te leveren. Om de snelheid van uw team te bepalen, moet u een zeer beperkt aantal user stories definiëren – geschat in storypoints – en meten hoe lang het duurt om deze set te leveren. Nadat u de snelheid een tijdje hebt gevolgd, merkt u dat de waarde uiteindelijk uitkomt op een stabiel minimum- en maximumaantal. Deze techniek werkt het beste voor het monitoren van een project. Andere technieken bestaan ​​wanneer je de totale kosten van een project bij de conceptie moet inschatten, maar dat is een verhaal dat ik later moet uitleggen.

Om een ​​lang verhaal kort te maken

Wat je moet onthouden hieruit is dat storypoints een inschatting zijn van grootte, inspanning en complexiteit voor een taak, en dat de waarde onafhankelijk is van de persoon die uiteindelijk het werk zal doen. De grootte, inspanning en complexiteit die wordt vertegenwoordigd door een enkele storypoint is alleen geldig voor de groep mensen die de schatting in de eerste plaats heeft gedaan. De waardes van de storypoints van één team kunnen niet worden vergeleken met die van een ander team. Je moet weten dat velocity, de snelheid is waarmee één enkele storypoint kan worden afgeleverd. De velocity moet op regelmatige basis worden berekend om uw team betrouwbare minimum- en maximumwaarden te bieden. Het voordeel van het weergeven van de grootte van een taak in storypoints door meerdere mensen, is dat u een hoge mate van vertrouwen krijgt in de nauwkeurigheid van de toegewezen waarde.

Ik hoop dat je deze post leuk vond.

Als je een opmerking of vraag hebt, laat het me dan weten in de commentaar sectie hieronder.