Opdrachtgevers willen graag een schatting van (nog) te bouwen functionaliteit, ook als het werk “agile” uitgevoerd gaat worden. Dat lijkt mij volkomen terecht. Om te schatten zijn in de ICT twee benaderingen gangbaar: werken met functiepunten of werken met storypunten. Functiepunten kennen we al sinds de 70’er jaren. Werken met storypunten is relatief nieuw en vooral door agile werken sterk aan populariteit gegroeid. Soms wordt geclaimd dat de ene methode wel werkt en de andere niet. Maar dit ligt heel wat subtieler.
Wanneer werkt wat nu het beste? Hierbij mijn inzichten op die vraag en mijn tips uit de praktijk.
Wat zijn storypunten, wat zijn functiepunten?
Functiepunten zijn een absolute maat voor de complexiteit van een systeem. Het is een wereldwijde ISO-standaard, net als de meter of de kilogram is vastgelegd. Functiepuntanalyse werkt ruwweg als volgt:
– Schat de complexiteit van het systeem door tellen van (minimaal) het aantal externe interfaces, de query’s, het aantal input- en output schermen plus de hoeveelheid databronnen.
– Vermenigvuldig dit met een factor voor de gewenste kwaliteitsattributen van het systeem. Hoe hoger de kwaliteit, hoe groter de factor. Dit geeft een absoluut getal, het aantal functiepunten.
– Raadpleeg dan een benchmark over het benodigd aantal uren per functiepunt, extern of binnen je eigen organisatie, en je weet de omvang van het werk als input voor je planning.
– Deze schatting vindt plaats door een expert in functiepuntanalyse, wat kan aan de hand van een ontwerpschets, vaak ondersteunend met een tool of spreadsheet dat de gegevens omzet in schattingen in tijd en geld.
Storypunten zijn een relatieve maat voor de inspanning dat een team moet verzetten voor een stukje werk, meestal een user- of technische story of op hoger niveau een feature. Als een story vier punten groot wordt geschat, is die story dus tweemaal zoveel werk als een story van twee punten, maar verder is de schaal totaal betekenisloos. Het aantal punten wordt geschat door het team dat het werk moet verrichten door stories te vergelijken met eerdere teamervaring. Het belangrijkste hulpmiddel is overleg, vaak ondersteund met planningspoker.
Een team komt tot een schatting van een systeem door de totale backlog met daarin al het werk op punten te schatten. Als bekend is hoeveel punten een team in een sprint afwerkt (de velocity) volgt de doorlooptijd.
Als het team een aantal stories af heeft, ontstaat een (al beter) beeld wat een punt kost in de tijd (de velocity). Op basis van deze ervaring kunnen dan schattingen in tijd en geld gegeven worden.
Wanneer storypunten, wanneer functiepunten?
Ik zie tenminste drie belangrijke doelen van al het telwerk:
1: Vooraf schatten
Onzekerheden in beide methoden zitten zowel in het aantal geschatte punten (complexiteit) als in de schatting van de productiviteit (benchmark/velocity). Het maakt dan een groot verschil of een team ervaren is of niet.
Op basis van storypunten schatten met weinig ervaren teams is erg onbetrouwbaar. Immers: het team heeft dan nog weinig data (eerdere stories) om relatief op te schatten, is daar mogelijk ook nog niet erg bedreven in en de velocity van het team is ook nog niet bekend. Gebruik van functiepunttellingen en een benchmarks die hopelijk zo goed mogelijk aansluit bij de eigen situatie (systeem, branch, volwassenheid, cultuur, tooling, …) is dan het beste. Het resultaat is een schatting van een enkele expert die schat op basis van globale karakteristieken.
Als het team wel ervaring heeft kan er wel geschat worden op basis van vergelijkingsmateriaal. Met de dan eveneens bekende team velocity is een schatting af te geven. Het schatten is dan een team effort: ieder uit het team zal zijn inbreng geven over de omvang en vanuit de dialoog komt de planning. We gebruiken dan de expertise van de mensen die het moeten gaan maken en die schatten op basis van hun praktijk.
Mijn conclusie: is er ervaring, gebruik die dan ook en dan lenen storypunten zich hier prima voor. De schatting komt dan uit de praktijk en vanuit de mensen die het werk doen. Is die er niet, gebruik dan functiepunten.
2: Bewaken en bijstellen
Als je eenmaal begonnen bent wil je graag weten of je op koers ligt. Startte je al met storypunten, dan zie ik geen enkele reden om nu op functiepunten over te stappen. Maar stel dat je begon met functiepunten, bij gebrek aan ervaring. Wat dan?
Bij agile werken realiseer je sprintsgewijs stories. Stories mappen niet op functiepunten. Het team bouwt immers niet de afzonderlijk geschatte elementen/componenten uit de functiepuntanalyse in een sprint, bijvoorbeeld een database of een scherm, maar bouwt stories met typisch een stukje van een database, een stukje scherm en een beetje interface tegelijk. Of het team bouwt stories waar deze elementen helemaal niet inzitten, of tijdelijke workarounds of refactorings! Allemaal werk. Functiepunten zijn niet geschikt voor de sprint microplanningen van het team. Daarom dient een onervaren team vanaf sprint één toch over te gaan in schatten in storypunten.
Na enige tijd bouwt zich dan ervaring op, bijvoorbeeld na drie tot vijf sprints en volgt alsnog een schatting op basis van storypunten. Het team is in enige mate ervaren. Is er nu 10% van de storypunten af, dan kun je gaan extrapoleren naar de eindstreep. Een redelijke aanname is dat het project nog negen maal zo lang duurt.
Dan kan dus ook de eerder afgegeven planning op basis van functiepunten vergeleken gaan worden. Komt die schatting op storypunten nu op hetzelfde neer als de eerder gegeven functiepunten schatting? Wijkt dit getal af, dan moet dit gerapporteerd worden, want de praktijk mag niet genegeerd worden.
3: Benchmarken
En wat als we achteraf willen weten hoe productief we waren vergeleken met andere organisaties? Of wat als we dit team van onze outsourcingspartner graag willen vergelijken? Of wat als we willen weten “hoeveel IT” we nu in huis hebben vergeleken met andere organisaties? In dit geval helpen storypunten niet, ze zijn immers een relatieve en niet gestandaardiseerde maat. Functiepunten zijn hier dan de aangewezen weg.
Tips
Tenslotte nog wat tips uit mijn praktijk:
1. Bij onbekende of zeer sterk veranderende specificaties werkt uiteraard geen enkele methode! Bespreek dit met de opdrachtgever. Natuurlijk mag dit. Maar wordt het dan time-to-budget?
2. Trap niet in de valkuil om vooraf alle stories of componenten te gaan benoemen. Redeneer als volgt: we bouwden eerder systeem A met X storypunten, het nieuwe systeem schatten we als driemaal zo complex, dus op driemaal X punten. Zo simpel kan het zijn! Natuurlijk kan het ook fijnmaziger, alhoewel in mijn praktijk vaak achteraf blijkt dat dit verbazingwekkend weinig toevoegt. Dit kan maanden van planningseffort terugbrengen tot uren.
3. Zorg voor een goede dialoog. Schatten is geen polderen of wie het hardste roept!
4. Hou teams in stand en zet ze in op vergelijkbaar werk. Zo blijft ervaring in stand en blijft het schatten met storypunten maximaal betrouwbaar.
5. Wees helder over de marges in je planning. Hanteer bandbreedtes in zowel geschatte punten als in de benchmarks/velocities.
6. Pas op: functiepuntanalyse telt in de ISO-standaard geen “business-logic” complexiteit mee. Bevat jouw systeem daar veel van, dan dien je daar waarschijnlijk voor te corrigeren.
7. Gebruik de tips uit methodieken als SAFe of LeSS als met meerdere teams gewerkt wordt, om toch met storypunten te kunnen blijven werken.
8. Als je de schatting afgegeven door een ervaren team toch niet vertrouwt, ga dan eens goed na hoe dat komt. Waarschijnlijk is er dan iets aan de hand in je agile organisatie wat nog weer beter kan. Bespreek dat! Want verbeteren past uitstekend bij Agile!