Att Uppskatta Arbete i Agila Projekt
I ett agilt projekt, när teamet planerar kommande sprintar, skapas ”berättelser”. En sådan berättelse definierar en enskild funktion, en inkapslad aktivitet med tillhörande beskrivning och acceptanskriterier.
Sprintarna pågår oftast i två till fyra veckor. Under den tiden behöver teamet avgöra hur mycket arbete de kan ta sig an, utan att överskrida sprintens tidsram.
I traditionella, icke-agila projekt, skulle man i regel uppskatta arbetet i arbetsdagar. Det skulle innebära att man räknade hur många heltidsanställda som behövdes för att slutföra en uppgift. Man utgick alltså från dagar och antalet personer i sina beräkningar.
Men i agila projekt ser det annorlunda ut. Man räknar inte längre i dagar eller personer. Faktum är att det är förbjudet att räkna i något som ens liknar mandagar. Istället låter man teamet omvandla arbetet till ett allmänt accepterat värde som representerar den sammantagna uppskattningen.
Vad exakt värdet är spelar inte så stor roll. Det vanligaste är att använda ”Story Points” (berättelsepoäng). De brukar baseras på Fibonacci-sekvensen, som börjar 0, 1, 2, 3, 5, 8, 13, 21 och så vidare. Varje tal är summan av de två föregående. Detta hjälper till att tydligt skilja berättelsens komplexitet, eftersom varje högre tal är betydligt större än det föregående.
Men man behöver inte nödvändigtvis använda ”story points”. Man kan lika gärna använda t-shirtstorlekar (XXS, XS, S, M, L, XL, XXL) eller varför inte djur från ett zoo, för att representera storleken på en uppgift.
Oavsett vilken skala man väljer, handlar det om teamets gemensamma känsla för vilket värde som bäst representerar uppgiftens komplexitet. Det handlar absolut inte om tidsåtgång. Teamet ska ju slutföra varje berättelse inom den givna sprintens tidsram, så tiden är en konstant.
Faktorer som Påverkar Uppskattningen av Story Points
En uppskattning av story points handlar inte bara om hur svår en uppgift är. Teamet måste väga in flera olika aspekter när de bestämmer det slutgiltiga värdet.
Den slutgiltiga uppskattningen ska alltså representera en kombination av alla dessa faktorer, uttryckt i ett enda värde. Här är några av de viktigaste aspekterna:
#1. Teknisk Svårighet
Om vi antar att vi uppskattar berättelser för ett utvecklingsteam, kommer den tekniska svårigheten att vara en av de första sakerna som teamet tar hänsyn till.
Det är ett rimligt förhållningssätt. Ett team med tekniska experter är bäst lämpade att bedöma denna aspekt av en berättelse. De kan tänka på saker som:
- Hur jämför sig denna berättelse med andra, redan genomförda, ur ett tekniskt perspektiv?
- Hur många kodfiler behöver teamet skapa/ändra för att slutföra berättelsen?
- Hur många kodändringar kommer berättelsen att orsaka i andra, relaterade system?
- Hur komplicerad blir algoritmen eller processlogiken att implementera?
#2. Externa Beroenden och Risker
Det är förvånansvärt hur ofta en berättelses framgång i en sprint är beroende av insatser från andra team eller personer utanför teamet.
Berättelser som teamet kan genomföra helt på egen hand är lättast att uppskatta. Men det blir mer komplicerat när teamet är beroende av extern hjälp. Personer utanför teamet kommer naturligtvis inte att prioritera teamets uppgifter, vilket teamet måste ta med i beräkningen när de uppskattar arbetet.
Hur mycket denna faktor höjer uppskattningen beror till stor del på teamets tidigare erfarenheter och hur stort det externa beroendet är. Med tiden brukar teamet utveckla en känsla för hur mycket externa faktorer kan påverka slutförandet av en berättelse.
#3. Återanvändbarhet
En annan viktig aspekt är hur mycket av det befintliga materialet som teamet kan återanvända för att slutföra berättelsen. Om delar av lösningen redan finns, behöver teamet inte börja från noll, utan kan återanvända delar av den befintliga lösningen och därmed jobba snabbare.
Återanvändbarhet kan alltså sänka den totala uppskattningen, även om själva uppgiften i sig kan vara ganska komplicerad.
#4. Kunskap om Teamet
En viktig faktor som traditionell uppskattning med mandagar aldrig kan ta hänsyn till är hur väl teamet känner sina egna styrkor och förmågor.
När teamet jobbar ihop under flera sprintar lär de känna varandra. De förstår vem som är bra på vad. Denna kunskap kan de ta med i beräkningen vid uppskattningen.
Om en berättelse kräver en viss teknisk expertis som teamet besitter, kommer uppgiften inte att vara så svår. Men om den nödvändiga kompetensen saknas, kommer teamet att behöva mer tid på sig att sätta sig in i ämnet, vilket måste återspeglas i uppskattningen.
Hur Uppskattningen Går Till
Varje uppskattning ska vara en laginsats. Ingen enskild person ska på egen hand bestämma en berättelses komplexitet. Målet är att teamet ska diskutera uppskattningen tills alla är eniga om ett värde som representerar uppgiftens svårighetsgrad.
Teamet kan göra uppskattningen direkt i samband med sprintförfiningen, ett möte där man diskuterar och förtydligar berättelserna. Alternativt kan man avsätta en dedikerad tid för uppskattning.
Exempel på Uppskattningsprocess
- Välj ett uppskattningsverktyg som teamet ska använda, till exempel Planning Poker, en Miro-tavla eller liknande.
- Placera en berättelse på tavlan. Låt teamet diskutera och ställa frågor om berättelsen, så att alla har en gemensam förståelse innan uppskattningen börjar.
- Starta uppskattningen. Varje gruppmedlem väljer ett värde från Fibonacci-skalan.
- När alla har uppskattat, går man igenom resultaten tillsammans och diskuterar dem. Vanligtvis kommer teamet att vara oense om två eller tre värden. De som har valt det lägsta värdet får förklara varför, medan de som har valt de högre värdena får presentera sina argument. Målet är att lägga alla argument och överväganden på bordet så att alla förstår uppgiften.
- Efter diskussionen görs en ny uppskattningsrunda. Nu brukar teamet ha landat på ett eller två värden. Diskussionen upprepas. Beroende på hur situationen ser ut, kommer teamet antingen överens om ett av de två värdena, eller så görs ytterligare en uppskattningsrunda.
- Uppskattningen är klar när alla teammedlemmar är nöjda med det slutliga värdet. Det ska vara en överenskommelse mellan hela teamet, inte bara ett fåtal individer. Eftersom berättelserna senare kan tilldelas vem som helst i teamet, är det viktigt att alla är överens om hur svår uppgiften är.
Sprintplanering
Teamet har nu en ”backlog” med berättelser som alla har blivit uppskattade. Helst har de även fått en prioritering, så att teamet vet vilka berättelser som ska tas med i nästa sprint.
Under planeringsmötet väljer teamet ut berättelser till den kommande sprinten. Beslutet om vilka berättelser som ska väljas grundas på följande faktorer:
✅ De högst prioriterade berättelserna prioriteras först.
✅ Teamet ska utgå från sina erfarenheter om hur många story points de brukar kunna klara av i en sprint. Detta är något som teamet lär sig med tiden och genom erfarenhet. Det tar oftast flera sprintar att få en god uppfattning om detta.
✅ Man ska inte bara titta på antalet story points och prioritet. Man måste även tänka på hur kompetensen i teamet fördelas mellan de valda berättelserna. Om teamet till exempel bara har två front-end utvecklare, bör man kanske inte välja berättelser som enbart fokuserar på front-end. Det skulle leda till överbelastning på de två personerna medan resten av teamet inte har så mycket att göra. Teamets kunskap ska alltså gå hand i hand med effektiviteten i sprinten.
Teamets Kapacitet
Teamets kapacitet (för den kommande sprinten) är en annan viktig faktor. Det är ett värde som inte har något att göra med det totala antalet story points, men som anger hur mycket tid teamet har att arbeta under den kommande sprinten.
För att kunna planera sprintens innehåll på bästa sätt behöver man alltså väga in båda aspekterna:
- Teamets kapacitet – Mätt i dagar. En teammedlems tillgänglighet under en hel dag motsvarar en dags kapacitet. Om ett team på 10 personer till exempel är fullt tillgängliga under en sprint på två veckor, motsvarar det en kapacitet på 100.
- Det genomsnittliga antalet story points som teamet genomför i en sprint – Mätt i story points. Detta värde kommer från teamets tidigare erfarenheter och hänger nära samman med teamets kapacitet.
Det tar tid och övning att hitta rätt balans.
Fördelar och Vanliga Misstag
Det är förvånansvärt hur mycket team kan krångla till övergången till ett agilt arbetssätt. Det känns ibland som att man måste ”förstå” konceptet innan man ens kan börja arbeta på det sättet.
Detta första steg är tyvärr också det svåraste. I vissa fall kan det ta flera år, särskilt i strikta och konservativa företagskulturer.
Men när teamet väl ”förstår” hur det funkar, kommer följande saker att hända:
- Man behöver inte längre räkna i personer eller dagar för att veta när en uppgift kan slutföras.
- Teamet lär sig att skapa berättelser som passar in i en sprint. Om en berättelse är för stor, delas den upp i mindre berättelser.
- Teamet gör bra uppskattningar och vet exakt när saker och ting kommer att vara klara.
- Det ökar teamets pålitlighet och förutsägbarhet.
- Alla i teamet ”är på samma våglängd”. De kommer att se samma saker när de tittar på en berättelse. Efter ett tag kanske de inte ens behöver göra uppskattningar, utan bara se en siffra i huvudet och inse att alla ser samma siffra, och på så sätt veta hur mycket som kan göras under en sprint.
Det här är några vanliga problem som uppstår när team inte förstår hur de ska jobba agilt:
- De håller fast vid de gamla metoderna med mandagsuppskattningar. De omvandlar allt till dagar eller antal personer som är inblandade. Story points eller Fibonacci-tal betyder indirekt, eller direkt, antalet dagar.
- Ledningen jämför team baserat på antalet story points som levereras i varje sprint. Detta är helt fel. Det grundläggande felet är att man inte förstår att varje team uppskattar story points på olika sätt. Det finns absolut ingen anledning att synkronisera uppskattningarna mellan olika team.
- Ett teams story point kan representera att man ritar en cirkel, medan ett annat team kan använda det för att representera att man ritar ett hus med platt tak, fyra fönster och två dörrar. Och det är helt okej.
- Ibland tenderar team att uppskatta nästan allting mellan två till fyra olika siffror. Kanske för att de är rädda att om en berättelse får siffran 123, så kommer någon att tro att det har med antalet dagar att göra. Men Fibonacci-skalan är ju oändlig. Vi behöver inte begränsa oss till 3, 5 eller 8.
- Uppskattningen domineras av seniora personer, som på så sätt bestämmer vad alla andra ska tycka. Vi ska aldrig låta en gruppmedlem påverka uppskattningen. Alla har rätt att uttrycka sin åsikt och bli lyssnade på.
Slutord
Det är inte alltid lätt att byta från traditionell uppskattning till agil, varken för teamet eller för ledningen. För att det ska fungera måste båda sidor förstå processen. Om någon av dem inte förstår uppstår en jobbig period av motstridiga förväntningar.
Men när allt väl faller på plats, kommer magiska saker att börja hända. Teamen kommer att göra bättre uppskattningar och planera sitt arbete på ett mer effektivt sätt, medan ledningen får mer förutsägbara lanseringar och färdplaner att lita på.
Kolla även in ohälsosamma processer som kan förstöra din sprint.