ORDINA BLOGT

Got my point? - van uren naar SP

  • Ronald Bottelier
  • 31 oktober 2015

 

Photo credit: free estimates : san francisco (2013) via photopin (license)

Als voorbeeld, om het schatten in story points (SP’s) te promoten heb ik een keer een terugrekening uitgevoerd naar SP's vanuit gerealiseerde modulen die in uren waren begroot. Reverse engineering uit nieuwsgierigheid. Compleet onzinnig  om in de praktijk te doen, maar het leverde goede gespreksstof op om management -dat nog niet vertrouwd was met storypoint estimation- inzicht te geven in de kracht van SP’s. Het opende ogen, omdat het verschil ontdekt werd tussen het schatten in storypoints en in uren. En het hielp om anders te leren denken dan in de vertrouwde uren (1 uur = X euro).
I’ll show you how.

Vooraf (1): Om geen verkeerde indruk te wekken: uren zijn ongelijk aan SP´s! – Per definitie.
Vooraf (2): Terugrekenen van uren naar SP’s is in de praktijk onzin en zinloos. Dat gebeurt nooit. Ik doe het hier om te laten zien hoe story point estimation zich verhoudt tot inschatten in uren.
Vooraf (3): Ik ben geen wiskundige, dus in dit verhaal zijn vast gaten te schieten. Het is een illustratie.

Een lang verhaal met een happy end (en een nooduitgang).
Let’s go!

Brongegevens

Genoemde uren hieronder komen uit een old-style releasematige projectsetting. Vooraf werden modulen begroot in hele uren per discipline (Design, Build, Test). Voor het begrip “module” kun je hier ook “user story” of “backlog item” lezen. In de uitvoering administreerde het team dagelijks de gemaakte uren per module. Achteraf werd per module afgerekend met het klantproject (uur*tarief). Een release had een capaciteit, uitgedrukt in uren.

SP modulen-uren

Stap 1: Van SP’s naar percentages

Om de SP’s op de gemaakte uren te kunnen projecteren, heb ik eerst van beide grootheden percentages berekend. Voor de SP reeks is de bekende fibonacci reeks gekozen van 0 SP tot 40 SP. De hoogste waarde uit het deck is 100% genoemd. De andere SP waarden zijn lineair naar percentages berekend. In Excel natuurlijk.

Tussenresultaat:

 SP storypoints-percentage

Stap 2: Van uren naar percentages

Dit heb ik gedaan door de brontabel te sorteren op uren, de grootste waarde 100% te noemen en de kleinste waarde 0%. Nu is “percentage” de sleutel tussen SP tabel en in de brontabel.  Simple as that.

Tussenresultaat:

SP modulen-uren-percentages

Stap 3: Projecteren van de SP’s op de uren in de brontabel

Tenslotte projecteer ik de SP's op de uren, op basis van de percentages. En ziedaar: de “synthetische” story points!  Story points teruggerekend vanuit uren (nogmaals: zinloos in de praktijk!).

SP modulen-uren-synthetischeSP

So what?

Dit is de nooduitgang. Het verband is gelegd, hier kan mijn blog stoppen. (Neem je de nooduitgang, bekijk dan eerst de tabel nog eens goed. En succes met story point estimation!).

Voor de nieuwsgierigen. Per module kunnen we nu in detail kijken naar de (achteraf) toegekende SP’s versus de werkelijk geadministreerde uren. Een eerste observatie is dat SP’s niet samenvallen met één hard getal aan uren. Modulen die vooraf (fictief) 5 SP waren gescoord, hebben kennelijk in werkelijkheid 72 tot 92 uur gekost. 

SP zoom op 5SP

Module_012 t/m 014 van elk 5 SP hadden kennelijk een sunny en een rainy resultaat.

Maar is dat niet raar?

Nee. Dit toont de kracht van story point schattingen. SP’s zijn geen uren, maar een relatieve eenheid waarmee het team de omvang van hun werk inschat, ten opzichte van andere modulen. Omdat een sprint of release bestaat uit meer dan één module, werkt de wet van de grote getallen. Sommige modulen zullen bij realisatie minder tijd kosten dan geschat, en anderen meer. Als een module rainy uitvalt, wordt dat statistisch gezien goed gemaakt door andere modulen die sunny zullen uitvallen.

Een sprint voorbeeld

Een team van 8 personen werkt fulltime in een sprint van 3 weken. Vooraf worden de modulen gescoord met planning poker. Het team verwacht -vooraf- in de sprint 50 SP te kunnen verwerken.
De theoretische (harde) capaciteit in uren is 960 uur (uitgaand van 100% beschikbaarheid).

SP theoretische capaciteit

Aan het eind van de sprint kan het resultaat in uren er als volgt uitzien. In kolom 3 een voorbeeld met een sunny scenario, en in kolommen 4 en 5 een gemiddeld en rainy scenario.

SP modulen-uren-SP-sunny-rainy

Volgen we het nog? Denk aan het happy end.
Dus de initieel geschatte 50 SP per sprint kunnen in werkelijkheid tussen de 720 en de 970 uur kosten? Maar mijn capaciteit was 960 uur.
Hé… Dan heb ik capaciteit over!

SP rest capaciteit

Wat betekent dit?

Dat het team gaandeweg de sprint ontdekt dat ze meer modulen kan realiseren dan ze initieel had ingeschat. We kunnen nu ook iets zeggen over de verwachte velocity. Naar verwachting zal de velocity per sprint verbeteren, omdat het team leert van yesterdays weather.

SP velocity

Wat kost dat?

Voor de klant (vaak een project) betekent dit, dat zijn of haar module met grote kans gerealiseerd is voor het vooraf ingeschatte aantal story points. Maar de prijs is onzeker, want prijs is uren*tarief. Het aantal te besteden uren per module is vooraf niet bepaald. Dat kan pas achteraf berekend worden. Dat wordt dus een verrassing. De prijs van een hele sprint kan per sprint hetzelfde blijven. Het aantal gerealiseerde modulen, SP’s en de prijs per module zal variëren. 

Is dat erg?

Nee. Het is anders, een andere perceptie.
Als de omvang van modulen in uren is geschat en als de voortgang in uren wordt gerapporteerd, is de perceptie dat een module “uitloopt” die vooraf was ingeschat op 72 uur, maar nu gerapporteerd wordt op 83 uur. Dat wordt als negatief ervaren en dat levert spanning op. Maar als we in de tabel kijken bij Module_12  zien we dat achteraf de marge van 5 SP tussen 72 uur en 92 uur lag. Bij een tussenrapportage van 83 uur hoeft er dus niets aan de hand te zijn! Relax.

Omdat het team per sprint steeds beter leert schatten, zal een SP steeds goedkoper worden en de productiviteit groeien. Als afrekening met een klantproject per module nodig is, kan dat in principe nog steeds op basis van werkelijke geregistreerde uren. Zoals geadministreerd in de eerste tabel.

Happy end?

Volgens mij wel.
Dit voorbeeld hielp mij in mijn uitleg aan managers die aan het kantelen zijn van het denken in vertrouwde uren naar vertrouwde story points. Teams weten al lang dat inschatten in story points prettiger is dan in uren. Teams moeten we niet vermoeien met uren schattingen. Dat kunnen ze helemaal niet! Relatief schatten met behulp van story points kunnen ze wel.

Afsluitend is het belangrijk om te realiseren dat velocity en SP’s alleen lokaal waarde hebben, voor één bepaalde team en product. Een module van 5 SP uit releasestraat 1 kan een hele andere omvang in uren hebben dan een 5 SP module uit een andere releasestraat. En.. uren zijn ongelijk aan SP´s!

Dus. Zo ging dat ongeveer. Weg met de urenschatting. Da's niet voor mensen. Leve de story points!
Got my point? 

 

 

Over de auteur:

Ronald Bottelier

Ronald Bottelier heeft een breed scala van projecten geleid, van software development voor telecom tot de verhuizing van Oracle productie databases, van de realisatie van een landelijke GIS applicatie met 3D topografie tot de inrichting en lancering van een corporate brand portal. Hij kent het (Agile) PM spel, zowel aan opdrachtgevers- als aan leverancierszijde. Zijn plezier en inspiratie komen uit zijn streven naar optimale samenwerking met klant en teams en het PM maatwerk dat voor ieder project nodig is. Hij maakt deel uit van de practice Digital-PM.