Estimering

Estimering är nödvändigt för att planera in en rimlig arbetsmängd i en iteration och skapa pålitliga prognoser för vad som kan ingå i en release. Traditionellt estimeras aktiviteter i timmar men agila projekt använder ofta relativa estimat. Det finns några riktlinjer för hur agila projekt kan arbeta med trovärdiga estimat som inte är för tidskrävande.

Vad som ska prioriteras av produktägaren, intressenternas representant, är beroende av det värde som leveransen medför och kostnaden för att leverera den. Ett lågt värde till en hög kostnad får därmed i regel en låg prioritering. Att kombinera större viktiga önskemål från projektets intressenter med några enklare men viktiga önskemål är ett bra sätt att driva projektet framåt.

De större viktiga önskemålen mår ofta bra av att brytas ner i mindre delar, så som att dela in sökfunktionaliteten i en enkel och en avancerad variant. Genom att låta större funktionalitet utvecklas iterativt kan både projektdeltagare och användare få en bättre förståelse för hur slutprodukten ska se ut och fungera.

Teamet estimerar

De som ska utföra arbetet, i Scrum är det exempelvis teamet, är också de som ska estimera hur lång tid något tar att göra. Det innebär att teamet behöver avsätta tid för att estimera det som ligger i projektets aktivitetslista, Product backlog. Estimeringen kräver delaktighet från någon som representant projektets intressenter, så som produktägaren eller liknande roll, som kan besvara frågor från teamet.

Relativa estimat

Att estimera i timmar är bekvämt. Det är konkret, det går att följa upp och det går att planera in resurser baserat på hur många timmar som projektet behöver förbruka för att bli klara. Enda problemet är att estimat i timmar inte är hållbart utan endast en indikation på hur långt något tar att göra under rådande omständigheter – när något ändras stämmer det inte längre och estimeringen behöver göras om. I agila projekt där förändringar är en naturlig del av processen innebär det att estimeringar behöver göras om ofta – vilket värde ger det?

Att använda relativa estimat är ett enkelt sätt att frikoppla saker som ska göras från timmar. Enklaste sättet är att använda sig av ett poängsystem som delas in i fem nivåer. Första nivån, 1, är värd två poäng och följande nivåer är värda dubbelt så många poäng som den föregående. Så nivå 2 är värt 4 poäng, nivå 3 är värt 8 p, 4=16p och 5=32p. Välj ut en enkel men vanlig funktion och ge den nivå 2. Gå därefter igenom varje post i er aktivitetslista, Product backlog, och besluta om aktiviteten är enklare är dubbelt så krävande som något annat.

Resultatet blir en lista där varje post är estimerad i poäng. När teamet inleder sin första iteration väljer de ut en rimlig arbetsmängd från listan, bryter ner det i aktiviteter som de tidssätter i timmar och slår fast som målsättnigen med iterationen (Sprint backlog i Scrum). Teamet kommer varje iteration leverera ett antal poäng, vilket är deras veolicty. Genom att analysera historiken, hur många poäng de har levererat i varje iteration, kan en prognos beräknas för kommande iterationer. Läs mer om det i release planering.

Planning poker

Hur lång tid något tar att göra beror på vem du frågar. Erfarenhet och kunskap spelar lika stor roll som hur personen uppfattar uppgiften. Lika viktigt är det att alla i teamet har en gemensam bild av vad som ska göras (alla tolkar uppgiften på olika sätt) och har en gemensam uppfattning om hur tidskrävande uppgiften är (eftersom de har gemensamt ansvar för leveranserna).

För att skapa trovärdiga estimat är det klokt att låta teamet estimera var för sig och tillsammans samtidigt. En populär metod för att uppnå det är planning poker.

Uppdaterades: 2011-12-01 10:49:57