Story points pokeren is passé. Ons devies is: schat de omvang van het werk in uren.
Scrum is een waardevolle en veel toegepaste software ontwikkelmethodiek. Aan de toepassing ervan zit echter een aantal haken en ogen. In deze blog denken we na over hoe het beter kan. Met Scrum. Deze keer ligt de focus op productiviteit.
Iets over de context
MetaFactory bouwt software.
Maar een beetje anders.
MetaFactory heeft tooling ontwikkeld waarmee we kunnen metaprogrammeren. Wat betekent dat we het ontwikkelproces zélf kunnen automatiseren.
En dat leidt, aantoonbaar, tot een veel hogere productiviteit en kwaliteit dan bij vergelijkbare projecten die handmatig worden geprogrammeerd. We hebben een crew met eersteklas Java ontwikkelaars, die gedeeltelijk aan interne projecten en gedeeltelijk aan projecten van klanten werken. Zowel intern als extern werken ze volgens Scrum.
Wat opvalt bij veel Scrum projecten bij onze klanten
- De ontwikkelaars hebben het over het algemeen naar hun zin.
- En kunnen dingen doen omdat het leuk is: “Laten we Kubernetes eens proberen.”
- Men maakt zich over het algemeen niet druk over productiviteit.
The Art of Doing Twice the Work in Half the Time
Niet zomaar een losse frase, maar de ondertitel van het boek dat SCRUM introduceert [1].
Mijnheer Sutherland claimt hier niets minder dan een productiviteitsverhoging van 400%. Dat noem ik lef hebben. In zijn boek maakt hij niet echt hard waar hij dit op baseert en in de praktijk ben ik een dergelijke productiviteitswinst nog nooit tegengekomen.
Wel het tegenovergestelde, van een bevriende testmanager bij Schiphol bagage: “Sinds onze softwareleverancier Agile is gaan werken, duurt alles twee keer zo lang.”
Productiviteit, effectiviteit en efficiëntie
Het begint met een klant die iets nodig heeft, dat voor hem een beoogde ‘Business Value’ genereert. Daarvoor wordt een project opgetuigd dat erop gericht is om precies te leveren wat de klant nodig heeft. Niet meer en niet minder: dat noemen we ‘effectiviteit’. Effectiviteit omvat echter meerdere kwaliteitsaspecten. Een MINI clubman bijvoorbeeld is een geweldig goede auto. Maar als je hem aan een klant levert die een ton aan vracht moet kunnen vervoeren, lever je niet wat hij nodig heeft. Je levert onvoldoende functionaliteit en dus onvoldoende kwaliteit.
‘Efficiëntie’ is, dat je zoveel mogelijk levert tegen een zo gering mogelijke inspanning (lees hier voor het gemak: uren of euro’s).
‘Productiviteit’ wordt vaak gedefinieerd als: productiviteit = effectiviteit x efficientie.
Als de wensen van de klant goed vertaald zijn naar te bouwen functionaliteit, zal de effectiviteit in de buurt van de 1 moeten komen. Mits er doelgericht gebouwd wordt zonder hobbyisme en onnodig ‘rework’, fixen van bugs, et cetera.
Dan komen we voor het berekenen van de productiviteit uit op:
productiviteit = efficiëntie = geproduceerde functionaliteit / inspanning (in uren of euro’s).
Heb je een Functiepuntanalyse (FPA) uitgevoerd, dan kan je de getelde functiepunten gebruiken als geproduceerde functionaliteit. Heb je geen FPA achter de hand, dan moet je terugvallen op de tweede methode.
De tweede en meest gebruikte is: productiviteit = geraamde uren** / bestede uren.
** Dit zijn de oorspronkelijk geraamde uren, van voordat het werk aan de story gestart werd.
Dit levert ook een goede basis voor een Earned Value berekening, die een objectieve maat geeft voor de voortgang van een project.
Je hebt dus functiepunten of geraamde uren en in beide gevallen de bestede uren nodig.
Ramen van de omvang van het werk
Er zijn mensen met een absoluut gehoor. En sommigen kunnen heel nauwkeurig afmetingen schatten. Maar de meesten zijn slecht in absoluut schatten.
Daarom bedacht mijnheer Sutherland een manier om de omvang van het werk relatief te schatten. Bijvoorbeeld in ‘honden’: “is deze klus een chihuahua, een boxer of een Deense dog?”
De meeste mensen kunnen goed overweg met relatief schatten. Toch zijn ‘honden’ niet echt handig. Net zomin als ‘fietsen’ om een kostprijs in uit te drukken.
Als zo’n relatieve schaal werkt en past bij onze manier van waarnemen, dan is de kans groot dat hij lijkt op de Fibonacci reeks. Daarom heeft Sutherland die gekozen voor zijn Story Points. Haalt hij er ook nog even de ‘gulden snede’ bij, maar dat terzijde.
Uit [1]:
(…) What using the Fibonacci sequence to calculate task size permits is estimates that don’t have to be 100 percent accurate. (…)
Hij laat ons de omvang van het werk schatten op een relatieve schaal die verwijst naar een ‘referentie-story’. Zowel de schatting als de referentiestory zijn sterk team-gebonden. Dat maakt het resultaat niet meer bruikbaar om productiviteit mee te meten en te vergelijken. Een bijkomend voordeel vindt hij dat de schattingen niet 100% nauwkeurig hoeven te zijn.
“Hoe gaat het met de voortgang van jullie werk?”
“Ik kan er niet veel over zeggen, want we schatten liever niet zo nauwkeurig.”
Het vervelende is dat Story Points dus geen omvang aangeven, maar (teamafhankelijke) inspanning. Vaak vertaald naar complexiteit. Niemand weet dan meer wat een Story Point waard is. Dan krijg je dit (uit [4]):
Als developer nooit meer afgerekend worden op een verkeerde inschatting
Ben je developer en bekend met SCRUM?
Wel eens een User Story gehad waarbij je veel meer uur hebt besteed dan vooraf ingeschat?
Tip: gebruik Story Points, hieronder lees je hoe wij hiermee bezig zijn.
Het idee van scrum is dat het team zelf continu werkt aan het verhogen van de velocity – lees: het verhogen van het aantal punten gerealiseerd per sprint in de tijd. Daardoor ontstaat er punt-inflatie. Waar we eerder onze neus stootten bij een 3 punter, gooien we nu voor vergelijkbaar werk maar 5 punten op en daarna 8. Moet je zien wat dat doet met je velocity …
Gewoon uren schatten
Dat mensen slecht zijn in uren schatten, en techneuten zijn notoire optimisten, is geen reden om het niet te doen. In de eerste plaats weet je dat het een schatting betreft, die is per definitie niet 100% nauwkeurig, en al gauw ken je je pappenheimers (“Ja, Fred zit altijd een factor 2 te laag.”). Overigens wordt het schatten gemakkelijker naarmate de periode waarover geschat wordt korter is. Zeg, vier weken voor een sprint moet te overzien zijn.
In de tweede plaats leert de schatter ervan als je bijvoorbeeld bij het tijdschrijven geplande uren, gemaakte uren en uren-te-gaan terugkoppelt. Dat betekent wel dat je de uren dan per story moet registreren. Bij MetaFactory doen we dat met onze urenadministratie die gekoppeld is met Jira. Bij bijna alle projecten, waarbij de klant de regie voert, wordt er op zeer globale codes tijdgeschreven en is niet bij te houden hoeveel uur er aan een bepaalde story wordt gewerkt.
Laat degene, die de story gaat uitvoeren, zelf schatten. Overleg met de rest van het team is prima. Maar laat hem of haar zelf de verantwoordelijkheid nemen voor de schatting en de uitvoering. Bij een verschil tussen geraamde en gemaakte uren kan dan beter gekeken worden waar dat vandaan komt. Vaak worden werkzaamheden redelijk goed ingeschat, maar wordt een aantal gewoonweg vergeten om mee te nemen in de raming.
Dat iemand wordt afgerekend op een foute inschatting is geen reden om de methodiek te wijzigen. Het is een heel goede reden om niet bij dat bedrijf te willen werken.
Conclusie
Als je echt grip wil hebben op kosten en tijd binnen je Agile project, dan moet je gewoon uren schatten in plaats van punten.
Dan kan je ook met je klant een zinnig gesprek voeren over wat zijn wensen kosten.
Referenties
| [1] | SCRUM The Art of Doing Twice the Work in Half the Time Jeff Sutherland 2014 ISBN 978-1-847-94110-7 |
| [2] | The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game Ken Schwaber & Jeff Sutherland 2020-Scrum-Guide-US.pdf |
| [3] | Scrum.org The Home of Scrum https://www.scrum.org/resources/blog/10-tips-product-owners-business-value |
| [4] | ELEVEN, Teeuwis Hillebrand, 1 augustus 2019 https://www.eleven.nl/blog/scrum:-uren-vs-story-points/ |
