Velocity – Eller hur åtta timmar blir fyra poäng.

Planning Poker tror jag att de flesta som är bekanta med Agil systemutveckling känner till, en metod för tidsestimering där hela gruppen estimerar de aktiviteter som ska genomföras i en sprint. Till hjälp finns en kortlek med siffrorna 0,1,2,3,5,8,13,20,40 och 100. Anledningen till att det är så många små tal och så få höga tal är att aktiviteter ska vara så små att de ska ta 1-2 dagar att genomföra. Ju längre tid en aktivitet beräknas ta desto större osäkerhet innebär det. Har man många aktiviteter på 20, 40 eller till och med 100 poäng bör man istället bryta ner dem till mindre aktiviteter.

Vad betyder då dessa siffror? Är det timmar? Någon pratar poäng, någon annan bananer, vinglas har jag stött på. Hur ska man tänka egentligen?

En första tanke är att det vore självklart att använda timmar, men det är inte det som är tanken. Siffran är tänkt att symbolisera en ideal arbetstimma i just ditt projekt/förvaltning. När allting flyter fritt från störningsmoment. Hur hittar man denna siffra då? Ta en uppgift som är väldefinierad som alla i gruppen är överens tar 4 timmar att göra. Låt denna bli er referensaktivitet. Utför sedan denna uppgift och se hur lång tid den faktiskt tar. Säg att den tar 8 timmar. Enhetstester måste ändras, incheckning mot rätt bransch, frågor ställs till beställaren till exempel. Uppgiften tog således 8 timmar istället för 4. Slutsatsen blir då att det tar oss 8 timmar att åstadkomma 4 timmars jobb. Förstår du nu problemet med att estimera i timmar. Byt istället ut ordet timmar efter 4 till poäng. Då blir förra meningen istället. Det tog oss 8 timmar att åstadkomma 4 poäng.

Om du nu delar antalet poäng med antalet timmar tillgängliga får du siffran 0,5. Den siffran är den som kallas för Velocity. Vad har man då för nytta av den?

Vi flyttar oss till Sprint Planeringen, kärnan i den agila systemutvecklingsmodellen Scrum. Det är tre veckor kvar till nästa demo för beställaren. Hur ska din gruppen veta hur mycket arbete de kan ta åt sig kommande sprint. Säg att det är 3 utvecklare på heltid, ingen semester planerad eller liknande. 360 timmars arbete finns inom ramen för sprinten. Då estimerar vi aktiviteter i Backlogen för 360 timmar och sen tar vi åt oss det. Enkelt. Eller?

Det är här vi har nytta av vår velocity. Genom att se tillbaka på föregående Sprintar och lära oss hur lång tid saker och ting faktiskt tar går det att göra korrekta estimat. I vårt enkla exempel ovan fick vi fram att Velocityn var 0,5. Därför borde gruppen ta Velocityn gånger antalet tillgängliga timmar för att få en mer rättvis bild och korrekt tidsuppskattning.

Men säger då någon ska man beräkna Velocity bara på en aktivitet?

Nej då säger jag. Det tar ett tag för en grupp att hitta sin Velocity. Stirra er inte blinda på en aktivitet. Titta istället på varje sprint. Dela antalet åstadkomna poäng med den tillgängliga tid som fanns och för statistik över er velocity. Efter ett antal sprintar kommer ni inse att ni hamnar ganska likt i sprintarna.

När velocityn är stabil kan man sedan göra en grov tidsuppskattning av sin Backlog för att enkelt se om projektet/förvaltningen kommer att kunna leverera på utsatt tid eller om något i Backlogen måste prioriteras antingen upp eller ner för att kunna nå målet.

Annonser

4 kommentarer

  1. Bra enkel beskrivning men jag tror att du menar fokusfaktor där du istället skriver velocity.

    Definitionen av hastighet är: Hastighet ,som mäts i poäng ,är en empirisk iaktagelse av teamets kapacitet att färdigställa arbete per iteration.

    Fokusfaktorn används för att få fram hur mycket av tillgänglig tid som faktiskt kan spenderas på verkligt arbete i sprinten.

    Fokusfaktor består av en fast och en rörlig del. Den fasta är standardmöten kopplade till metoden, releaseaktiviteter, driftsättning etc.

    Rörlig fokusfaktor är all tid som inte går att hänföra till den fasta faktorn. Tex extra möten som påverkar den tid teamet spenderar på att färdigställa funktionalitet i pågående sprint.

    • Helt korrekt. Jag är ute och cyklar lite där. Klart att det ska vara fokusfaktor. Jag har nog blivit lite färgad av mitt nuvarande projekt. Tack för synpunkten

  2. Hej, väldigt bra beskrivet. Tack.
    Jag har dock en fråga, min produktägare vill veta vad varje aktivitet kostar i tid och pengar, för det är en viktig input till prioriteringen för henne. Och vi har inte riktigt hittat någon bra väg fram där. Vi uppskattar productbacklogs alla aktiviteter och därefter blir de prioriterade för nästa sprint. Vi ger en uppskattning på SP och talar om ungefär hur många timmar de kommer att kosta. Men det känns lite konstig. Har du något bra tips för oss.

  3. Tack för din fråga,
    Jag vet inte riktigt hur era tidsuppskattningar ser ut i Product Backlog i förhållande till sprint backlog. Men en idé är att ha en övergripande estimering på alla krav/behov i antal dagar i Product Backlog. Därefter flyttar ni in dessa krav/behov till Sprint Backlog och bryter ner dessa i mindre aktiviteter och estimerar i timmar istället. På så vis får ni två separata tidsuppskattningar. En övergripande och en detaljerad. Fördelen här är att den övergripande går snabbt att göra och går lätt att ändra och den detaljerade görs såpass sent så att den blir väldigt säker.

    Här kommer ett exempel på hur man kan räkna ut vad en aktivitet kostar i pengar. Om man räknar med att en poäng motsvarar en timmes effektivt arbete och man vet att man i sprinten har en fokusfaktor på ca 70 %. Kan du ta antalet timmar delat på 0,7 för att få ut en mer rättvisande fingervisning i hur många faktiska timmar det kommer att ta att få aktiviteten färdigställd. Därefter är det bara att gångar det faktiska timantalet med timpriset. Det är ett sätt att göra det.

    Hoppas detta svar hjälpte lite.

    Mvh Johan

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Google-foto

Du kommenterar med ditt Google-konto. Logga ut /  Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s