Waarom gebruiken we Story points?

 André Heijstek, directeur van Valueminds:

‘We gebruiken vaak story points als manier om elementen in te schatten in Scrum projecten. Waarom gebruiken we ze, en waarom zouden we story points gebruiken om iets in te schatten, als we dit ook met uren kunnen doen?

Om die vraag te kunnen beantwoorden, moeten we eerst even kijken naar het concept velocity. Wanneer je goede story points hebt, kan dit namelijk zorgen voor een waardevolle definitie van velocity.  Laten we analogie gebruiken om dit te illustreren:

Stel, je plant een vakantie met de auto vanaf Gouda (waar ik toevallig woon), naar Nice in Frankrijk. Google Maps laat meteen zien dat de hele trip 1351 KM is. Als ik de duur van de trip snel wil inschatten, doe ik dit als volgt:

Ik schat in dat de gemiddelde velocity 100 KM per uur is (normaal gesproken rij ik een beetje sneller, maar de ervaring leert mij dat je vaak word gehinderd op de weg, en ik niet veel sneller ga dan dit gemiddelde).

De totale tijd van de trip zal dus 13,5 uur duren. Laten we daar nog twee uur rust aan toevoegen, en we kunnen de tijd van aankomst inschatten.

We hebben nu dus een plan voor het project, we weten de totale grootte (1351 KM) en we hebben een tijd geschat voor de duur van het project (15,5 uur). Tijdens het project willen we onze progressie meten.

Het meten van progressie in uren is niet slim. Als er wegwerkzaamheden zijn rondom Rotterdam en ik sta 2 uur lang stil, is mijn progressie geschat in uren 2 uur, maar mijn echte progressie bijna niks. Wanneer je progressie in uren wil meten, zal dit me niet helpen om mijn tijd van aankomst te herschatten (tenzij alles precies volgens plan gaat).

De enige manier om op een juiste manier progressie te meten, is door de resultaten te meten. We kunnen dit doen door het aantal kilometers op het dashboard te bekijken, maar dat voelt wel heel erg als micromanagement. Je kan niet altijd naar het dashboard kijken: je moet ook het verkeer in de gaten houden.

Een veel betere manier is om de mijlpalen van de afstand te meten:

Mijlpaal Afstand (km) Duur in uren, cumulatief
Antwerpen 100 1
Brussel 150 1,5
Luxemburg 350 3,5
Pauze 4,5
Nancy 500 6
Dijon 700 8
Lyon 900 10
Pauze 11
Orange 1100 13
Marseille 1200 14
Nice 1350 15,5

Let op het volgende:

  1. de mijlpalen zijn niet allemaal precies van dezelfde afstand. Het zou fijn zijn als alle grote steden op mijn trip precies op 100 km afstand van elkaar liggen, maar dat is natuurlijk niet realistisch.
  2. Mijn schattingen van de afstand zijn niet exact, maar afgerond op 50 km. Nog exactere schattingen zijn niet nodig. Wanneer ik aan het rijden ben, weet ik nooit precies of ik Nancy heb bereikt of niet. Ik zal bijvoorbeeld eerst langs de afslag noord-Nancy komen, daarna door het centrum rijden en tot slot door zuid-Nancy rijden. Wanneer ik een van deze afslagen op ongeveer 6 uur na mijn vertrek bereik, weet ik dat ik nog steeds op schema lig. Het exact inschatten van wanneer ik bepaalde plekken heb bereikt zal er alleen maar voor zorgen dat ik mijn trip ga micromanagen en ga denken ‘ik ben drie minuten te laat!’, waardoor ik word afgeleid van de échte progressie die ik maak.

Laten we dit nu terugbrengen naar software projecten.

De velocity is het gemiddelde aantal van story points die een team kan opbrengen in een sprint (gelijk aan mijn gemiddelde snelheid van 100 KM per uur). Een story point is een indicatie van de grootte of de duur van de taak die we in een sprint kunnen opleveren. Een story moet klein genoeg zijn om met het team verschillende mijlpalen te behalen tijdens de sprint om onze progressie te meten. Mijn persoonlijke voorkeur is dat een sprint  6-10 stories heeft.

Wanneer je minder stories per sprint gebruikt (zeker wanneer het er minder dan 3 zijn), gaat dit gepaard met een aantal nadelen:

  • Ik kan niet in detail voorspellen of ik mijn doelen behaal, die ik had van te voren had gepland.
  • Er is een goede kans dat de laatste story in deze sprint niet volledig wordt opgeleverd. Wanneer dat gebeurd, heeft 50% of 33% van mijn sprint gefaald. Dat is een slecht resultaat. Wanneer ik 10 stories in de sprint heb, en ik heb de laatste niet gehaald, heb ik een resultaat van 90%. Dit is nog steeds niet perfect, maar wel een goed resultaat.

Meer stories betekent meer administratie, en we hebben hier natuurlijk allemaal een hekel aan.

Dus, waarom gebruiken we story points?

  • We willen onze business value (story points) meten, niet onze kosten (uren). Het meten van kosten is zinloos, want kosten worden hoger door tijd (ons team zit op z’n plaats, hun uren worden gebruikt, hun salaris wordt betaald) losstaand van welke progressie er is gemaakt.
  • Het meten van relatieve waarden (is deze taak twee keer zo groot als die kleine taak?) is veel makkelijker voor mensen om in te schatten.
  • Story points zorgen voor een waardevolle indicatie van de velocity. Deze wordt groter wanneer we leren om slimmer te werken.
  • De velocity zal alle typische afleidingen bevatten (koffie halen, standaard meetings), zonder dat we deze apart moeten administreren, dus minder bureaucratie.’
0 antwoorden

Plaats een Reactie

Meepraten?
Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site wordt beschermd door reCAPTCHA en GooglePrivacy PolicyenServicevoorwaarden toepassen.

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.