Agile-schattingstechnieken

Abstract

Het schatten van de werkinspanning in agile-projecten verschilt fundamenteel van traditionele schattingsmethoden. De traditionele aanpak is om te schatten met behulp van een “bottom-up” techniek: detail uit alle eisen en schat elke taak om die eisen te voltooien in uren / dagen, dan gebruik maken van deze gegevens om het project schema te ontwikkelen. Agile projecten daarentegen gebruiken een “top-down” benadering, waarbij gebruik wordt gemaakt van grove schattingstechnieken op functiepakketten, en vervolgens progressieve elaboratie en rolling-wave planningsmethoden worden gebruikt om naar het taakniveau te gaan op een just-in-time basis, waarbij iteratief meer en meer detail wordt blootgelegd op elk niveau lager. Dit artikel gaat dieper in op twee veelgebruikte technieken voor agile schattingen (planning poker en affinity grouping), en gaat in op hoe de resultaten van deze oefeningen input leveren voor het voorspellen van planning en budget.

Top-down vs. Bottom-up

De traditionele methode voor het schatten van projecten is om aan het begin van een project enkele weken of maanden te besteden aan het definiëren van de gedetailleerde eisen voor het te bouwen product. Zodra alle bekende eisen zijn verzameld en gedocumenteerd, kan een Gantt chart worden gemaakt met alle taken die nodig zijn om de eisen te voltooien, samen met elke taak schatting. Middelen kunnen dan worden toegewezen aan taken, en acties zoals laden en nivelleren helpen om de uiteindelijke leveringsdatum en het budget te bepalen. Dit proces staat bekend als een bottom-up methode, omdat alle details met betrekking tot het product moeten worden gedefinieerd voordat de projectplanning en -kosten kunnen worden geschat.

In de software-industrie heeft het gebruik van de bottom-up methode ernstige nadelen als gevolg van de huidige snelheid van verandering. Snelheid van verandering betekent dat de snelheid van nieuwe ontwikkeltools en de snelheid van toegang tot nieuwe kennis zo groot is, dat elke vertraging in de oplevering iemand blootstelt aan concurrerende alternatieven en het gevaar inhoudt een verouderd product op te leveren (Sliger, 2010).

De top-down methode pakt dit belangrijke probleem aan, door gebruik te maken van de informatie die op dat moment beschikbaar is om ramingen op bruto niveau te maken. Rolling-wave planning wordt vervolgens gebruikt om nieuwe informatie op te nemen als het wordt geleerd, verder te verfijnen schattingen en iteratief uit te werken met meer detail naarmate het project vordert. Deze methode om net genoeg te leren om te beginnen, met een plan om meer kennis op te nemen naarmate de werkoutput evolueert, stelt het projectteam in staat om snel te reageren op tegenslagen en veranderende marktvraag.

Ramingstechnieken

Ramingstechnieken op globaal niveau worden gebruikt door teams die agile benaderingen gebruiken, zoals Scrum en Extreme Programming, en dit artikel zal twee van de populairste technieken behandelen: Planning Poker en Affinity Grouping. Schattingseenheden die worden gebruikt zullen ook worden onderzocht, omdat deze eenheden zodanig moeten zijn dat ze niet kunnen worden verward met tijd.

Planning Poker

De meest populaire techniek van bruto niveau schatting is Planning Poker, of het gebruik van de Fibonacci-reeks om een puntwaarde toe te kennen aan een functie of item (Grenning, 2002). De reeks van Fibonacci is een wiskundige getallenreeks die in de 13e eeuw werd geïntroduceerd en werd gebruikt om bepaalde vormaspecten van de natuur te verklaren, zoals de vertakking van bomen. De reeks wordt gegenereerd door de twee voorgaande getallen bij elkaar op te tellen om de volgende waarde in de reeks te krijgen: 0, 1, 1, 2, 3, 5, 8, 13, 21, enzovoort. Voor agile schattingsdoeleinden zijn sommige getallen veranderd, wat resulteert in de volgende reeks: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Deze getallen worden weergegeven in een set speelkaarten (zie Exhibit 1). De teamleden spelen “Planning Poker” (Bijlage 2) om een schatting te maken in de vorm van een puntwaarde voor elk item. Dit zijn de stappen:

• Elk teamlid krijgt een set kaarten.
• De bedrijfseigenaar (die NIET mag schatten) presenteert het item dat moet worden geschat.
• Het item wordt besproken.
• Elk teamlid selecteert privé een kaart die zijn/haar schatting weergeeft.
• Als iedereen klaar is, worden alle geselecteerde kaarten tegelijkertijd opengelegd.
• Als alle teamleden dezelfde kaart hebben gekozen, dan is die puntwaarde de schatting.
• Als de kaarten niet hetzelfde zijn, bespreekt het team de schatting met de nadruk op de afwijkende waarden:
  • Het lid dat de laagste waarde heeft gekozen legt uit waarom hij/zij die waarde heeft gekozen.
  • Het lid dat de hoogste waarde heeft gekozen legt uit waarom hij/zij die waarde heeft gekozen.
• Kies opnieuw tot de schattingen convergeren.
• Als er lange of “in het onkruid” gesprekken ontstaan, kunnen de teamleden een timer van twee minuten gebruiken om de discussie te timen, waarbij ze elke keer dat de timer afloopt opnieuw selecteren, totdat de discussie is afgerond.
• Herhaal dit voor elk item (Cohn, 2006, pp. 56-57).

Er zijn verschillende redenen waarom Fibonacci getallen worden gebruikt, en wel in dit formaat. De eerste reden is dat teams, wanneer zij eenmaal de tijd als basis voor de raming hebben geëlimineerd, minder geneigd zullen zijn om meer details te vragen en de ramingen op te vullen. Deze getallen vertegenwoordigen in plaats daarvan de relatieve omvang, niet de tijd. Het resultaat is dat de schattingsoefening vrij snel gaat. Teams besteden over het algemeen ongeveer twee minuten aan elk item, waardoor een backlog van 30 items in een uur kan worden ingeschat. Het feit dat teams beperkt zijn tot slechts 9 keuzes (d.w.z., puntwaarden of kaarten) helpt ook om het proces te versnellen.

De volgorde biedt ook het juiste niveau van detail voor kleinere en beter begrepen kenmerken, terwijl een vals gevoel van nauwkeurigheid voor hogere schattingen wordt vermeden. Bijvoorbeeld, een item met een hoge schatting (20 of hoger) betekent dat het item groot is en nog niet goed wordt begrepen. Debatteren over de vraag of het item een 20, een 19 of een 22 is, zou tijdverspilling zijn omdat er gewoon niet genoeg gegevens beschikbaar zijn. Zodra het item dichter bij de iteratie komt waarin het item zal worden bewerkt, kan het in kleinere stukken worden opgedeeld en in meer korrelige getallen worden geschat (1-13). Items met puntschattingen van 1-13 kunnen over het algemeen worden voltooid binnen een enkele iteratie (1-4 weken).

Het is belangrijk op te merken dat punten niet dezelfde betekenis hebben tussen teams; bijvoorbeeld, de “vijf” van het ene team is niet gelijk aan de “vijf” van een ander team. De teamsnelheid, die uit punten wordt afgeleid, mag dus niet worden gebruikt om de productiviteit tussen teams te vergelijken.

Affinity Grouping

Een nog snellere manier om te schatten, en een die wordt gebruikt wanneer het aantal te schatten items groot is, is affiniteitsgroeperen. Teamleden groeperen eenvoudig items van gelijke grootte, wat resulteert in een configuratie zoals die in Exhibit 3. De methode is eenvoudig en snel:

• Het eerste item wordt aan de teamleden voorgelezen en op de muur geplaatst.
• Het tweede item wordt voorgelezen en het team wordt gevraagd of het kleiner of groter is dan het eerste item; plaatsing op de muur komt overeen met het antwoord van het team (groter is naar rechts, kleiner is naar links).
• Het derde item wordt voorgelezen en het team wordt gevraagd of het kleiner of groter is dan het eerste en/of tweede item; het item wordt dienovereenkomstig op de muur geplaatst.
• De controle wordt dan overgedragen aan het team om de affiniteitsgroepering voor de rest van de items af te maken.

Teams kunnen ervoor kiezen om op dezelfde manier verder te gaan, door één item per keer op de muur te plaatsen na groepsdiscussie. Een snellere manier is echter om elk teamlid een item te laten kiezen en het te plaatsen op basis van hun eigen beste inzicht. Dit wordt gedaan met alle teamleden parallel werkend totdat alle items zijn beoordeeld en op de muur zijn geplaatst. Enkele honderden items kunnen in betrekkelijk korte tijd worden geschat. Zodra alle items aan de muur hangen, herziet het team de groeperingen. Items waarvan een teamlid denkt dat ze in de verkeerde groep zitten, worden besproken en indien nodig verplaatst.

Als het groeperen van affiniteiten is voltooid, kunnen schattingswaarden zoals punten worden toegewezen. In Exhibit 3, zou de eerste set uiterst links worden gelabeld als hebbend een waarde van 1 punt, de tweede set zou 2 punten zijn, de derde set 3 punten, de vierde set 5 punten, en de laatste set 8 punten.

Affiniteit groepering kan ook worden gedaan voor andere schattingseenheden, zoals T-shirt maten. Bijlage 4 toont een voorbeeld van gegroepeerde affiniteit items gelabeld met T-shirt maten in plaats van punten.

Estimation Units

Het gebruik van T-shirt maten (Extra Small , Small , Medium , Large , Extra Large ) is een andere manier om te denken aan relatieve maten van kenmerken. Dit is een nog grotere afwijking van het numerieke systeem, en zoals alle goede schattingseenheden op bruto-niveau kunnen ze op geen enkele manier worden geassocieerd met een specifieke tijdsduur.

Andere willekeurige maateenheden zijn Gummiberen, NUTS (Nebulous Units of Time), en foot-pounds. Teams kunnen hun eigen schattingseenheden creëren, en zoals u kunt zien, hebben ze daar vaak een beetje plezier in.

Dit artikel gaat niet in op het gebruik van op tijd gebaseerde eenheden, zoals ideale ontwikkelingsdagen en/of -uren. Deze zijn al gebruikelijk en worden goed begrepen, zodat de uitleg ervan niet is opgenomen. Het is echter de moeite waard op te merken dat ramingen op bruto-niveau meer succes kunnen hebben wanneer zij worden losgekoppeld van het begrip tijd. Omdat tijdsramingen vaak worden omgezet in toezeggingen door management en bedrijf, voelen teamleden meer druk om zo nauwkeurig mogelijk te zijn. Als gevolg daarvan vragen zij om meer en meer details over het item dat wordt geraamd. Dit verandert bruto-niveau schatting in de meer tijdrovende detail-niveau schatting en verslaat de oorspronkelijke bedoeling en doel.

Forecasting Schedule and Budget

Zodra bruto-niveau schattingen en team snelheid zijn bepaald, kunnen planning en budget worden voorspeld. Teams bepalen hun velocity door het totaal aantal punten op te tellen van alle items die ze in een iteratie hebben voltooid. Bijvoorbeeld, een team kan vijf items hebben geselecteerd met een totale puntwaarde van 23 punten (zie Figuur 5). Aan het einde van hun twee weken durende iteratie, waren ze slechts in staat om vier van de vijf items te voltooien. Hun snelheid is 15, of de som van de puntwaarden van de items 1-4. Teams krijgen geen “gedeeltelijk krediet” voor het voltooien van delen van een item, dus zelfs als zij aan item 5 waren begonnen, zou het niet tellen, aangezien het niet werd voltooid.

Determining the Schedule

De gemiddelde snelheid van een team wordt gebruikt bij het voorspellen van een langetermijnplanning. De gemiddelde snelheid wordt berekend door de snelheidsmetingen van de laatste drie iteraties van het team bij elkaar op te tellen, en dat totaal door drie te delen. Dus als een team 15 punten heeft gehaald in de eerste iteratie, en 20 punten in elk van de twee volgende iteraties, dan is de gemiddelde snelheid van het team 18 (15+20+20 / 3). Als een team gemiddeld 18 punten in een iteratie kan doen, en er zijn 144 punten aan werk te voltooien in het project, zal het team acht iteraties nodig hebben om het werk te voltooien (144 / 18). Als elke iteratie twee weken duurt, dan is de verwachte voltooiing 16 weken. Met deze methode kunnen we de vraag beantwoorden: “Wanneer zijn we klaar met al dit werk?”

Als het team een track record van velocity data heeft, is het mogelijk om de meest optimistische voltooiingsdatum te bepalen, de meest pessimistische, en de meest waarschijnlijke. Het gemiddelde snelheidsgetal van het team wordt gebruikt om het meest waarschijnlijke scenario te berekenen, terwijl de snelheidsgetallen van de slechtst presterende iteraties van het team worden gebruikt om de meest pessimistische verwachte voltooiingsdatum te berekenen. Het gebruik van de snelheid van de iteraties waarin het team meer dan verwacht heeft voltooid, levert de meest optimistische prognose op.

We kunnen deze getallen ook gebruiken om de vraag te beantwoorden: “We moeten iets opleveren op deze datum-van deze features, hoeveel hebben we er dan gedaan?” Zie Exhibit 6 voor een voorbeeld van de meest waarschijnlijke prognose van de hoeveelheid die voltooid zal zijn, de pessimistische prognose, en de optimistische prognose. Dit voorbeeld is voor een team waarvan de gemiddelde snelheid 20 is, en dat een slechtst presterende snelheid heeft van 12 en een best presterende snelheid van 25. Gegeven dit en slechts zes weken (drie iteraties), hoeveel kan er voltooid worden? De pessimistische voorspelling is dat alleen de items 1-8 in zes weken klaar zullen zijn. De optimistische prognose is dat de items 1-18 zullen worden voltooid. En de meest waarschijnlijke voorspelling, gebaseerd op de gemiddelde snelheid van het team van 20, is dat de items 1-13 in zes weken zullen worden voltooid.

Als teams niet-numerieke schattingseenheden gebruiken, zoals T-shirtmaten, zullen de algoritmen voor de voorspelling complexer zijn. Aanbevolen wordt de maten om te zetten in een numeriek systeem om gemakkelijker vergelijkbare gegevens te genereren. Zo zou een Small kunnen worden omgezet in een NUT van 3, een Medium in een NUT van 5, enzovoort. Deze kunnen ook worden omgezet in tijdsbereiken (een Small zou bijvoorbeeld 1-3 dagen kunnen zijn), maar dit is inherent riskant, vanwege problemen die reeds zijn genoemd in de sectie Schattingseenheden.

Bepaling van het budget

In dit deel kijken we naar het antwoord op de vraag: “We hebben maar zoveel geld – hoe lang gaat dat nog mee en hoeveel hebben we gedaan voordat het op is?” Eerst wordt een eenvoudige formule gebruikt om de kosten per punt te bepalen:

Σ (geladen team salarissen voor periode n) / punten voltooid in periode n

Neem de som van de salarissen van het team (geladen) voor een periode, zeg drie twee-weekse iteraties, en deel dat door het aantal punten dat het team in hetzelfde tijdsbestek heeft voltooid. Dus een team waarvan de totale geladen salarissen $240.000 bedragen over zes weken, en dat 60 werkpunten heeft voltooid in die drie iteraties, zou een kostprijs per punt hebben van $4.000. Gebruik nu de volgende formule om het budget te bepalen:

(Kosten per punt x totale puntwaarde van af te ronden punten) + andere uitgaven = voorspeld budget

Niet zelden zijn niet alle kenmerken voor een product gedefinieerd bij het begin van een project, wat zoals verwacht is voor agile projecten. De budgetramingen zijn dus gebaseerd op wat we vandaag weten, plus een voorspellingsalgoritme dat gebaseerd is op historische gegevens of advies van experts. Bijvoorbeeld, stel dat er tot nu toe slechts 20 features op de lijst staan, maar dat de business pas extra feature requests of verfijningen kan geven nadat is gezien hoe de eerste release door de klant wordt ontvangen. Het budget voor het project, dat is gepland voor drie releases, zou alleen prognosegegevens beschikbaar hebben voor de eerste release en niet voor het hele project. Het team zou het bovenstaande algoritme kunnen gebruiken om het budget voor de eerste release te voorspellen, en vervolgens uitgaan van 20% extra voor de tweede release en 5% extra voor de laatste release, op basis van ervaringen uit het verleden.

Zoals snelheid, worden budgetvoorspellingen en planningvoorspellingen elke iteratie herzien. Dit maakt deel uit van het rolling-wave planningsproces dat agile projecten onderschrijven.

Final Words

Niet behandeld in deze paper is het gebrek aan gestructureerde schattingstechnieken die worden gebruikt in lean-benaderingen zoals Kanban. In plaats van (verspilde) tijd te besteden aan het schatten van items, worden de gemiddelde cyclus- en doorlooptijden berekend op basis van de werkelijke doorvoersnelheden van het team. Kanban gebruikt de wiskundige stelling van de Wet van Little als basis voor zijn formules. Met behulp van doorlooptijdberekeningen die van cumulatieve stroomdiagrammen zijn afgeleid, kunnen teams projectplanningen voorspellen zonder vooraf tijd te hoeven besteden aan het maken van schattingen. De lezer wordt aangemoedigd onafhankelijk onderzoek te doen naar dit onderwerp, dat op zichzelf een aparte paper zou kunnen zijn.

Agile-projecten zijn bedoeld om een product of productstappen vroeg en vaak op te leveren, zodat feedback van klanten en andere learnings in de volgende release kunnen worden verwerkt. Door meer tijd te besteden aan experimenteren, uitvoeren en leren, en minder tijd aan speculeren, wordt de cyclustijd voor oplevering verkort. Agile teams zijn beter in staat om te concurreren op de markt en gelijke tred te houden met de steeds snellere veranderingen.