De Nesma Functiepunt­analyse en Agile schattings­methoden

Planning Poker met Story Points

Een andere methode, die nog veel vaker wordt toegepast bij Agile projectteams, is het inschatten van Sprint Backlog met behulp van Planning Poker. Planning Poker wordt, normaal gesproken, door het gehele Agile team samen gedaan. De te maken User Story wordt doorgesproken en daarna geeft elke teamlid daaraan een score. Deze scores worden “Story Points” genoemd. Alhoewel er voor het toepassen van Planning Poker ook geen formele methode beschreven is, wordt het vaak op dezelfde manier aangepakt. Dat gaat ongeveer als volgt: Het team spreekt af een bepaalde score-reeks te gebruiken, bijvoorbeeld de Fibonacci reeks (1, 2, 3, 5, 8, 13, 21, …). Daarnaast hanteert het team een in het verleden gemaakte, “gemiddelde” User Story als referentie en geeft die vaak 5 Story Points. Voor het inschatten van een nieuwe User Story wordt de hoeveelheid werk vergeleken met de referentie User Story. Dan kan de nieuwe story gelijk zijn en krijgt deze ook 5 Story Points, of kleiner en dan krijgt die 3 Story Points of veel kleiner en dan krijgt die 2 of 1 Story Points. Is de nieuwe User Story (veel) groter dan de referentie, dan worden 8, 13 of meer Story Points gegeven. Als elk teamlid zijn/haar score bekend gemaakt heeft, wordt dat besproken en wordt gezocht naar een consensus. Op deze manier wordt van een hele sprint de relatieve omvang van de User Stories ten opzichte van elkaar ingeschat. Uit ervaring weet het team hoeveel Story Points er normaal per sprint gemaakt worden (Velocity genaamd). Op deze manier weet de Product Owner ongeveer wat uit de volgende sprint als resultaat verwacht mag worden.

Voordeel van Planning Poker is dat het heel laagdrempelig is om uit te voeren. De regels zijn beperkt, het team moet even met elkaar een “norm” vinden, maar daarna kunnen ze vaak redelijk goed inschatten hoeveel werk zij in de volgende sprint kunnen verzetten. Sommige Agile teams gaan daar ook een “commitment” op aan. Nadeel van Planning Poker is ook hier weer dat er geen vast omschreven methode is en ook hier een behoorlijke mate van gevoel wordt ingezet. Doordat elk team op een andere wijze tegen hun “referentie User Story” aankijkt, zijn de uitkomsten niet over teams te vergelijken. Er zijn bedrijven die voor alle teams eenzelfde referentie gebruiken en kunnen daarmee nog wel iets vergelijken, maar dan weer zeker niet over bedrijven heen.

Functiepuntanalyse in Agile Projecten

Functiepuntanalyse, vaak afgekort tot FPA, is van een andere orde dan de twee hierboven beschreven schattingsmethoden. FPA is een officieel vastgelegde, ISO genormeerde aanpak om van een project de functionele omvang in te schatten. FPA is heel goed toepasbaar bij Agile Projecten – zie onze andere blog over dit onderwerp. Bij de FPA-aanpak neemt iemand die op de hoogte is van deze telmethode, met de Product Owner de Project of Sprint Backlog door. Op basis van de voorgeschreven methode wordt de hoeveelheid Functiepunten vastgesteld. De hoeveelheid functiepunten vermenigvuldig je met de normale productiviteit van het team en zo kun je ook een schatting maken hoeveel werk in een sprint gedaan kan worden.

FPA heeft hetzelfde voordeel als hierboven beschreven Agile schattingsmethoden, dat het snel en makkelijk toepasbaar is. Maar het heeft niet de nadelen dat het niet vergelijkbaar is. De FPA-methode levert een team onafhankelijke omvang op, die zelfs over organisaties heen vergelijkbaar is.

Verschil tussen Story Points en Functiepunten?

Wij horen nogal eens dat er gezegd wordt “Wij werken al met Story Points, wij hebben geen Functiepunten nodig”. Dan heb je geen goed begrip wat beiden methoden je organisatie kunnen bieden.

Het belangrijkste verschil tussen Story Points en Functiepunten is, dat Story Points een team inspanningsschatting oplevert, terwijl FPA de functionele omvang van een systeem bepaalt. Heel basaal gezegd is Story Points een vorm van uren inschatting, terwijl FPA de hoeveelheid gewenste functionaliteit uitdrukt, de output van je project dus. Het zijn dus echt twee verschillende eenheden, op beiden wil je voorspelbaar zijn.

Bij Planning Poker probeert een team elke sprint eenzelfde hoeveelheid Story Points op te leveren als output. De Velocity in Story Points van een team is normaal gesproken voor elke sprint gelijk en op termijn stijgend doordat Agile een aanpak is van continu verbeteren.

Bij het toepassen van FPA op sprints merk je dat de hoeveelheid op te leveren functionaliteit per sprint varieert. FPA gaat dan ook uit van een gemiddelde output over een periode van minstens een kwartaal. Daarom is het belangrijk dat een team beide methoden toepast. Met Planning Poker wordt de hoeveelheid inspanning ingeschat. Met FPA wordt de hoeveelheid output ingeschat.

Door gebruik te maken van meerdere schattingsmethoden worden Agile teams beter voorspelbaar. Wil je eens vrijblijvend sparren over het voorspelbaar maken van jouw Agile teams? Voel je welkom om contact met ons op te nemen!