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.