Storlek och tid i Scrum-projekt

Uppskatta funktioner i storlek och inte i tid

Produktägaren tillsammans med teamet har idéer på vilka funktioner/krav som ska vara med i releasen. För att kunna prioritera dem behöver produktägaren bl.a. veta storleken på dem. Det viktigaste är inte att veta om en funktion tar 12 eller 13 timmar att utveckla. Det viktiga är att veta om funktion 1 är dubbelt så stor som funktion 2.

Antingen kan man då uppskatta kraven i timmar/dagar eller mer rekommenderat genom att använda en relativ skala. Syftet är inte att svara exakt 12 eller 13 timmar utan ge en grov uppskattning. Oftast när man anger uppskattningar i ideala timmar/dagar känner man att man behöver veta väldigt mycket mer om vad som ska göras för att inte ha fel, för man känner press eftersom det är relaterat till tid. Uppskatta i tid leder till längre diskussioner. Anger man istället i en relativ skala behöver man bara säga att krav 1 är lite större än krav 2 osv. Det är det produktägaren egentligen vill veta för att kunna prioritera.

I scrum kallas detta för Story Points. När man uppskattar dessa krav kan man använda sig av fibonacci nummer. De är 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. De som används i scrum är liknande och är 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Syftet med planeringen på denna nivå är prioritering av funktioner/krav och för att kunna ta fram en releaseplan.

När går man över till att uppskatta i tid?

Vid /Utvecklingstart dvs. när man närmar sig en sprint behöver man planera hur lång tid saker tar att utföra. Det är svårt i en sprint att veta hur nära man är målet om man arbetar efter en relativ skala. Då är det mycket lättare och tydligare att uppskatta den tid som är kvar tills kravet/funktionen är klar i tid. Därför uppskattar man kraven i en sprint och dess uppgifter i timmar.

Hur mäter man då framfart i ett Scrum-projekt?

Om man bara räknar i timmar i den sprint man befinner sig i hur vet man då hur man ligger till mot releaseplanen? När en sprint är slut kan man titta på hur mycket som blev levererat och godkänt. Genom att se de story points för de krav som blev godkända får man fram sprintens velocity.

Velocity är alltså ett mått på hur mycket som blev klart i en sprint mappat mot den enhet man uppskattade kraven. Om sprinten vid sprintstart innehöll 150 story points men några krav togs bort och de som blev levererade motsvarade 120 story points är alltså velocityn 120. Efter ett par sprintar kan man se en trend på hur mycket man hinner med i en sprint och kan då se teamets snitthastighet/velocity.

Det viktigaste är alltså att ta reda på hur mycket teamet klarar av att leverera i varje sprint (som då mäts i velocity). Därför är det mer intressant att veta att teamet kan hantera t.ex. 120 story points per sprint istället för att de jobbar på 120% eller endast 65% av teamets uppskattningar. Skillnaden är att man fokuserar på hur mycket teamet kan leverera istället för att jämföra mot uppskattningarna.

Om man har uppskattat alla krav i story points så kan man alltså få en uppskattning på hur många sprintar det är kvar till release utan att behöva uppskatta alla krav i timmar. Man låter story points visa storlek på krav och velocityn beräkna tiden. Man kan alltså efter ett par sprintar börja se hur velocity-trenden ser ut och tydligt kunna se hur många sprintar som behövs för att kunna lansera.

En annan stor fördel med att inte uppskatta allt i timmar eller dagar är om det visar sig att det går långsammare eller snabbare än väntat. Då behöver man inte uppskatta om alla krav utan man låter velocityn hantera tiden och tidplanen eftersom story points hanterar storleken. Enda gången man behöver planera om krav satta i story points är när de inte stämmer relativt.

Ola Wallin
2013-03-13