Agila uppskattningstekniker

Abstract

Att uppskatta arbetsinsatser i agila projekt skiljer sig fundamentalt från traditionella metoder för uppskattning. Det traditionella tillvägagångssättet är att uppskatta med hjälp av en ”bottom-up”-teknik: beskriv alla krav i detalj och uppskatta varje uppgift för att uppfylla dessa krav i timmar/dagar, och använd sedan dessa uppgifter för att ta fram projektplanen. I agila projekt används däremot en ”uppifrån och ner”-metod, där man använder sig av uppskattningstekniker på bruttonivå för funktionsuppsättningar och sedan använder sig av progressiv utarbetning och planeringsmetoder med rullande vågor för att borra sig ner till uppgiftsnivån just i tid, och där man iterativt upptäcker mer och mer detaljer för varje nivå nedåt. I den här artikeln kommer två vanliga tekniker för agil uppskattning (planeringspoker och affinitetsgruppering) att behandlas, liksom hur resultaten av dessa övningar ger input till prognostisering av tidsplan och budget.

Top-down vs. Bottom-up

Den traditionella metoden för uppskattning av projekt är att tillbringa flera veckor eller månader i början av ett projekt med att definiera de detaljerade kraven för den produkt som ska byggas. När alla kända krav har tagits fram och dokumenterats kan ett Gantt-diagram tas fram som visar alla uppgifter som behövs för att uppfylla kraven, tillsammans med en uppskattning av varje uppgift. Resurser kan sedan tilldelas uppgifterna, och åtgärder som t.ex. lastning och utjämning bidrar till att fastställa det slutliga leveransdatumet och budgeten. Denna process är känd som en bottom-up-metod, eftersom alla detaljer om produkten måste definieras innan projektets tidsplan och kostnad kan uppskattas.

I programvarubranschen har användningen av bottom-up-metoden allvarliga nackdelar på grund av dagens snabba förändringstakt. Förändringens hastighet innebär att hastigheten på nya utvecklingsverktyg och hastigheten på tillgången till ny kunskap är så stor att varje försening i leveransen gör att man är öppen för konkurrerande alternativ och riskerar att leverera en föråldrad produkt (Sliger, 2010).

Ovanifrån-och-ned-metoden tar itu med denna nyckelfråga genom att använda den information som för närvarande finns tillgänglig för att ge uppskattningar på bruttonivå. Rullande vågplanering används sedan för att införliva ny information allteftersom den kommer fram, för att ytterligare förfina uppskattningarna och iterativt utarbeta med fler detaljer allteftersom projektet fortskrider. Denna metod där man lär sig precis tillräckligt för att komma igång, med en plan för att införliva mer kunskap allteftersom arbetsresultaten utvecklas, gör det möjligt för projektgruppen att snabbt reagera på motgångar och förändrad efterfrågan på marknaden.

Skattningsmetoder

Skattningsmetoder på bruttonivå används av grupper som använder sig av agila metoder som Scrum och Extreme Programming, och den här artikeln kommer att behandla två av de mest populära metoderna: Planning Poker och Affinity Grouping. De skattningsenheter som används kommer också att undersökas, eftersom dessa enheter bör vara sådana att de inte kan förväxlas med tid.

Planeringspoker

Den mest populära tekniken för uppskattning på bruttonivå är Planning Poker, eller användningen av Fibonacci-sekvensen för att tilldela ett poängvärde till en funktion eller ett objekt (Grenning, 2002). Fibonacci-sekvensen är en matematisk talserie som introducerades på 1200-talet och användes för att förklara vissa formativa aspekter av naturen, t.ex. trädens förgrening. Serien genereras genom att addera de två föregående talen för att få fram nästa värde i sekvensen: 0, 1, 1, 2, 3, 5, 8, 13, 21 och så vidare. För agila uppskattningar har några av siffrorna ändrats, vilket resulterar i följande serie: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Dessa nummer representeras av en uppsättning spelkort (se bild 1). Gruppmedlemmarna spelar ”planeringspoker” (bilaga 2) för att ge en uppskattning i form av ett poängvärde för varje objekt. Här är stegen:

• Varje lagmedlem får en uppsättning kort.
• Företagsägaren (som INTE får göra en uppskattning) presenterar det objekt som ska uppskattas.
• Objektet diskuteras.
• Varje lagmedlem väljer privat ett kort som representerar hans eller hennes uppskattning.
• När alla är redo avslöjas alla valda kort samtidigt.
• Om alla lagmedlemmar har valt samma kort är det poängvärdet uppskattningen.
• Om korten inte är desamma diskuterar laget uppskattningen med tonvikt på de avvikande värdena:
  • Den medlem som valt det lägsta värdet förklarar varför han/hon valt värdet.
  • Den medlem som valt det högsta värdet förklarar varför han/hon valt värdet.
• Välj igen tills uppskattningarna konvergerar.
• Om långa eller ”in-the-weeds”-konversationer skulle uppstå kan gruppmedlemmarna använda en timer på två minuter för att tidsbegränsa diskussionen och välja igen varje gång timern tar slut, tills konverteringen sker.
• Upprepa för varje punkt (Cohn, 2006, s. 56-57).

Det finns flera anledningar till att Fibonacci-nummer används, och används i detta format. Det första är föreställningen om att när teamet väl har eliminerat tid som beräkningsgrund är de mindre benägna att kräva mer detaljer och fylla på beräkningarna. Dessa siffror representerar istället relativ storlek, inte tid. Detta leder till att uppskattningen går ganska snabbt. Grupperna ägnar i allmänhet ungefär två minuter åt varje objekt, vilket gör att en backlog med 30 objekt kan uppskattas på en timme. Det faktum att grupperna är begränsade till endast 9 valmöjligheter (dvs. poängvärden eller kort) bidrar också till att påskynda processen.

Sekvensen ger också rätt detaljnivå för mindre och bättre förstådda funktioner, samtidigt som man undviker en falsk känsla av noggrannhet för högre uppskattningar. Exempelvis innebär ett objekt med en hög uppskattning (20 eller högre) att objektet är stort och ännu inte välförstått. Att debattera huruvida objektet var 20, 19 eller 22 skulle vara slöseri med tid eftersom det helt enkelt inte finns tillräckligt med data att tillgå. När objektet närmar sig den iteration under vilken objektet kommer att bearbetas kan det delas upp i mindre delar och uppskattas i mer detaljerade siffror (1-13). Punkter med punktskattningar från 1-13 kan i allmänhet slutföras inom en enda iteration (1-4 veckor).

Det är viktigt att notera att poäng inte har samma innebörd i olika team; till exempel är ett teams ”fem” inte lika med ett annat teams ”fem”. Därför bör team velocity, som härleds från poäng, inte användas för att jämföra produktivitet mellan olika team.

Affinity Grouping

Ett ännu snabbare sätt att uppskatta, och som används när antalet objekt som ska uppskattas är stort, är affinitetsgruppering. Teamets medlemmar grupperar helt enkelt ihop objekt som är av samma storlek, vilket resulterar i en konfiguration som liknar den som visas i bild 3. Metoden är enkel och snabb:

• Den första punkten läses upp för gruppmedlemmarna och placeras på väggen.
• Den andra punkten läses upp och gruppen tillfrågas om den är mindre eller större än den första punkten; placeringen på väggen motsvarar gruppens svar (större är till höger, mindre är till vänster).
• Den tredje punkten läses och laget tillfrågas om den är mindre eller större än den första och/eller andra punkten; punkten placeras på väggen i enlighet med detta.
• Kontrollen överlåts sedan till laget för att avsluta affinitetsgrupperingen för resten av punkterna.

Lagen kan välja att fortsätta på samma sätt, genom att placera en punkt i taget på väggen efter gruppdiskussion. Ett snabbare sätt är dock att låta varje gruppmedlem välja ett föremål och placera det utifrån sin egen bästa förståelse. Detta görs med alla gruppmedlemmar som arbetar parallellt tills alla föremål har bedömts och placerats på väggen. Flera hundra objekt kan uppskattas på relativt kort tid. När alla föremål har satts upp på väggen går teamet igenom grupperingarna. Föremål som en gruppmedlem anser vara i fel grupp diskuteras och flyttas vid behov.

När affinitetsgrupperingen är klar kan värden för skattningsenheter, t.ex. poäng, tilldelas. I bild 3 skulle den första uppsättningen längst till vänster märkas med värdet 1 poäng, den andra uppsättningen skulle vara 2 poäng, den tredje uppsättningen 3 poäng, den fjärde uppsättningen 5 poäng och den sista uppsättningen 8 poäng.

Affinitetsgruppering kan också göras för andra skattningsenheter, t.ex. T-shirtstorlekar. Bild 4 visar ett exempel på affinitetsgrupperade objekt märkta med T-shirtstorlekar i stället för punkter.

Estimation Units

Användningen av T-shirtstorlekar (Extra Small , Small , Medium , Large , Extra Large ) är ett annat sätt att tänka på relativa storlekar av funktioner. Detta är ett ännu större avsteg från det numeriska systemet, och liksom alla bra uppskattningsenheter på bruttonivå kan de inte på något sätt förknippas med en specifik tidslängd.

Andra godtyckliga måttbenämningar är t.ex. gummibjörnar, NUTS (Nebulous Units of Time) och fotpund. Grupperna kan skapa sina egna uppskattningsenheter, och som ni kan se har de ofta lite roligt när de gör det.

Detta dokument täcker inte användningen av tidsbaserade enheter som ideala utvecklingsdagar och/eller timmar. Dessa är redan vanliga och välkända, så deras förklaringar har inte tagits med. Det är dock värt att notera att uppskattningar på bruttonivå har potential att bli mer framgångsrika när de är frikopplade från begreppet tid. Eftersom tidsuppskattningar ofta omvandlas till åtaganden av ledning och företag känner sig gruppmedlemmarna mer pressade att vara så exakta som möjligt. Som ett resultat av detta begär de mer och mer detaljerade uppgifter om det objekt som ska uppskattas. Detta förvandlar uppskattning på bruttonivå till mer tidskrävande uppskattning på detaljnivå och motverkar den ursprungliga avsikten och det ursprungliga syftet.

Förutsägning av tidtabell och budget

När uppskattningar på bruttonivå och teamets hastighet har fastställts kan tidtabell och budget förutsägas. Lag bestämmer sin hastighet genom att addera det totala antalet poäng för alla objekt som de slutfört under en iteration. Ett team kan till exempel ha valt fem objekt med ett totalt poängvärde på 23 poäng (se bild 5). I slutet av den två veckor långa iterationen kunde de bara slutföra fyra av de fem punkterna. Deras hastighet är 15, eller summan av poängvärdena för punkterna 1-4. Lag får inte ”partiell kredit” för att slutföra delar av ett objekt, så även om de hade börjat med objekt 5 skulle det inte räknas, eftersom det inte slutfördes.

Fastställande av schemat

Ett lags genomsnittliga hastighet används vid prognostisering av ett långsiktigt schema. Genomsnittlig hastighet beräknas genom att summera hastighetsmätningarna från lagets tre senaste iterationer och dividera summan med tre. Om ett team genomförde 15 poäng i sin första iteration och 20 poäng i var och en av de två efterföljande iterationerna är teamets genomsnittliga hastighet 18 (15+20+20+20 / 3). Om ett team i genomsnitt kan göra 18 punkter i en iteration och det finns 144 punkter i projektet som ska slutföras, kommer det att ta teamet åtta iterationer att slutföra arbetet (144 / 18). Om varje iteration tar två veckor, är det beräknade slutresultatet 16 veckor. Denna metod gör det möjligt att besvara frågan: ”När kommer vi att vara klara med allt detta arbete?”

Om teamet har en historik av hastighetsdata är det möjligt att fastställa det mest optimistiska slutdatumet, det mest pessimistiska och det mest sannolika. Lagets genomsnittliga hastighetstal används för att beräkna det mest sannolika scenariot, medan hastighetstal från lagets sämsta iterationer används för att beräkna det mest pessimistiska prognostiserade slutdatumet. Genom att använda hastigheten från iterationer där teamet kunde slutföra mer än förväntat får man den mest optimistiska prognosen.

Vi kan också använda dessa siffror för att besvara frågan: ”Vi måste leverera något till det här datumet – hur många av de här funktionerna kommer vi att ha slutfört till dess?”. Se bild 6 för ett exempel på den mest sannolika prognostiserade mängden som kommer att vara klar, den pessimistiska prognosen och den optimistiska prognosen. Exemplet gäller ett team vars genomsnittliga hastighet är 20 och som har en hastighet med sämsta resultat på 12 och en hastighet med bästa resultat på 25. Med tanke på detta och endast sex veckor (tre iterationer), hur mycket kan slutföras? Den pessimistiska prognosen är att endast punkterna 1-8 kommer att vara klara på sex veckor. Den optimistiska prognosen är att punkterna 1-18 kommer att slutföras. Och den mest sannolika prognosen, baserad på lagets genomsnittliga hastighet på 20, är att punkterna 1-13 kommer att slutföras på sex veckor.

Om lagen använder icke-numeriska uppskattningsenheter som t.ex. t-shirtstorlekar, blir algoritmerna för prognostisering mer komplexa. Det rekommenderas att storlekarna konverteras till ett numeriskt system för att lättare generera liknande data. Till exempel kan en Small konverteras till en NUT på 3, en Medium till en NUT på 5 och så vidare. Dessa kan också konverteras till tidsintervall (en Small kan till exempel vara 1-3 dagar), men detta är i sig riskabelt på grund av de problem som redan nämnts i avsnittet om uppskattningsenheter.

Bestämning av budget

I det här avsnittet tittar vi på svaret: ”Vi har bara så här mycket pengar – hur länge kommer de att räcka och hur mycket kommer vi att ha gjort innan de tar slut?”. Först används en enkel formel för att bestämma kostnaden per punkt:

Σ (teamets löner för period n) / poäng som slutförts under period n

Ta summan av teamets löner (loaded) för en tidsperiod, låt oss säga tre tvåveckors iterationer, och dela den med antalet poäng som teamet slutförde under samma tidsram. Så ett team vars totala löner uppgår till 240 000 dollar under sex veckor, och som slutförde 60 arbetspunkter under dessa tre iterationer, skulle ha en kostnad per arbetspunkt på 4 000 dollar. Använd nu följande formel för att bestämma budgeten:

(Kostnad per punkt x totalt poängvärde för de punkter som ska slutföras) + andra utgifter = prognostiserad budget

Softa är inte alla funktioner för en produkt definierade i början av ett projekt, vilket är som förväntat för agila projekt. Så budgetberäkningar baseras på vad vi vet idag, plus en prognosalgoritm som är baserad på historiska data eller expertvägledning. Säg till exempel att det bara finns 20 funktioner listade än så länge, men att verksamheten inte kommer att kunna ge några ytterligare önskemål om funktioner eller förfiningar förrän efter att ha sett hur den första versionen tas emot av kunden. Budgeten för projektet, som är planerat för tre versioner, skulle endast ha prognosdata tillgängliga för den första versionen och inte för hela projektet. Teamet kan använda algoritmen ovan för att prognostisera budgeten för den första versionen och sedan anta ytterligare 20 % för den andra versionen och ytterligare 5 % för den sista versionen, baserat på tidigare erfarenheter.

Likt hastigheten revideras budgetprognoser och tidtabellsprognoser varje iteration. Detta är en del av den planeringsprocess med rullande vågor som agila projekt följer.

Slutord

Det som inte tas upp i detta dokument är bristen på strukturerade uppskattningstekniker som används i lean-strategier som Kanban. I stället för att spendera (slösa) tid på att uppskatta objekt beräknas genomsnittliga cykel- och ledtider baserat på teamets faktiska genomströmningshastigheter. Kanban använder den matematiska teoremet Little’s Law som grund för sina formler. Med hjälp av ledtidsberäkningar som härleds från kumulativa flödesdiagram förutspår grupperna projekttidtabeller utan att lägga ner någon tid på att göra uppskattningar i förväg. Läsaren uppmuntras att göra oberoende forskning om detta ämne, vilket skulle kunna utgöra en separat artikel i sig.

Agila projekt är avsedda att leverera en produkt eller produktstegringar tidigt och ofta, för att införliva kundernas återkoppling och andra lärdomar i nästa utgåva. Genom att ägna mer tid åt att experimentera, genomföra och lära sig och mindre tid åt spekulationer förkortas cykeltiden för leverans. Agila team har bättre möjligheter att konkurrera på marknaden och hålla jämna steg med den ständigt ökande förändringstakten.