Varför du bör mäta ditt teams sprint-hastighet

När sprintviktigheten mäts korrekt kan den hjälpa dig att uppskatta teamets arbetsbelastning, förenkla sprintplaneringen och hjälpa projektledare att hålla koll på sina projekt.

Vad är en sprintvelocity?

Sprinthastighet är ett mått på hur mycket ett agilt team kan producera under en normal sprintcykel. Du använder två huvudvariabler för att beräkna sprintviktighet: hur mycket arbete ditt agila team har slutfört och hur lång tid det tog dem att slutföra arbetet.

Det är viktigt att notera att sprintviktighet är ett beskrivande värde och inte bör användas som ett framgångsvärde. Sprintviktighet bör inte ses som något att ”förbättra”. Det är ett svårt värde att beskriva hur mycket arbete ett team kan slutförd under en sprint. Även om du bör mäta sprintvelocity konsekvent bör det inte ses som ett framgångsvärde. Om så är fallet kan ditt team bli överarbetat. Målet med att förstå sprintviktigheten är att förstå teamets kapacitet, inte att öka den kapaciteten.

Beräkna sprintvelocity

Du kan beräkna sprintvelocity med en enkel matematisk formel: dividera antalet backlog-punkter (eller story points, om det är vad ditt team använder) med den totala längden på din sprint i dagar.

Om ditt team till exempel har 60 punkter i backloggen och din genomsnittliga sprintlängd är 2 veckor, ser ekvationen ut så här:

60 backlog-punkter/10 dagar = sprintvelocity på 6

Att ta reda på hur mycket ditt team kan slutföra under en genomsnittlig sprint är relativt enkelt. Börja med att ta itu med en backlog som har alltför många punkter och se hur många punkter ditt team kan slutföra under den önskade sprinttiden. Målet är inte att slutföra allt i backloggen, utan att få en referenspunkt för hur mycket arbete teamet kan slutföra.

Ett annat alternativ innan den första sprinten är att använda strategier för projektuppskattning för att förutsäga hur mycket teamet kan slutföra. Om du letar efter några strategier kan du prova att använda uppifrån-och-ner-uppskattning, trepunktsuppskattning eller den analoga uppskattningsmetoden.

Varför mäta sprinthastigheten?

Man mäter inte sprintvelocity bara för att, det finns praktiska (och fördelaktiga) anledningar till varför ditt team bör mäta sprintvelocity. Här är några.

• Gör sprintplanering enkelt. För produktägare och scrummästare kan det vara enklare att planera sprintar om de känner till teamets sprint-hastighet. Om du känner till teamets genomsnittliga sprint-hastighet är det lättare att välja rätt användarberättelser från produktbackloggen för att gå vidare till den här iterationen utan att överbelasta utvecklingsteamet.

• Hantera intressenternas förväntningar. Om dina intressenter ber om en tidslinje för en specifik användarberättelse, eller om de försöker lägga till något innan slutet av sprinten, förstår du som produktägare hur den ändringen kan påverka ditt teams resultat baserat på deras sprint-hastighet.

• Signalera potentiella problem. När du regelbundet spårar sprint-hastigheten kan du mäta den genomsnittliga hastigheten mer konsekvent. Om du ser en plötslig nedgång i hastigheten vet du att det finns ett potentiellt problem, till exempel ett hinder som en oavslutad beroenden, som måste lösas innan du går vidare till nästa sprint.

Visualisera sprintvelocity

Att kunna titta på och mäta sprintvelocity i en överblick kan hjälpa dem som arbetar med ett agilt projekt att snabbt förstå hur deras team presterar. När som helst under sprinten kan de ta en titt på ett diagram och se teamets nuvarande förlopp. 

Beroende på vad du vill visualisera för din sprint finns det några olika typer av hastighetsdiagram som du kan använda. Här är några exempel:

Grundläggande hastighetsdiagram

Ett grundläggande hastighetsdiagram är ett stapeldiagram som jämför två huvudfaktorer: den beräknade mängden arbete som utvecklingsteamet kan slutföra under en sprint och det faktiska arbetet som slutförs under en sprint. 

X-axeln i diagrammet visar olika sprintar, medan Y-axeln visar mängden story points eller användarberättelser.

När du ser det visuellt är det enkelt att se hur mycket teamet i genomsnitt kan slutföra under en viss sprint jämfört med den beräknade mängden.

Burndown-diagram

Ett burndown-diagram uppskattar mängden arbete som teamet behöver slutföra och jämför det med den tid som återstår av sprinten. När sprinten fortskrider är målet att grafen ska närma sig noll. 

Om du har en uppskattning av ditt teams hastighet kan du rita in den i ditt burndown-diagram och se hur ditt team ligger till jämfört med den idealiska hastighetslinjen. I exemplet ovan kan du se hur teamet tidigt i sprinten kunde slutföra mer arbete än förväntat från den ideala linjen. Så småningom minskade teamets arbete, men de nådde ändå slutmålet. 

Burnup-diagram

Ett burnup-diagram är raka motsatsen till ett burndown-diagram. Det här diagrammet har vanligtvis två linjer: det faktiska arbetet som har slutförts och det idealiska målet som du vill att teamet ska uppnå. Det ideala målet är vanligtvis en horisontell linje över diagrammet, medan det faktiska arbetet kontinuerligt växer för att nå mållinjen med tiden.

Tips för att reglera teamets sprint-hastighet

Om du märker att ditt teams sprint-hastighet är inkonsekvent kan det vara ett tecken på att du behöver reglera teamets hastighet. Det är viktigt att sprint-hastigheten är konsekvent eftersom det gör det enkelt att se teamets regelbundna prestationer. Inkonsekvenser visar när något är fel.

Till exempel hade fyra av dina senaste sprintar en sprint-hastighet på 4,5, 7, 5 och 3. Den genomsnittliga sprint-hastigheten är vanligtvis runt 6. Den inkonsekventa sprint-hastigheten kan vara en indikator på ett större problem. Att reglera ditt teams sprintvelocity innebär att försöka hålla sprintvelocity konsekvent från sprint till sprint.

Här är några tips på hur du kan reglera ditt teams sprint-hastighet.

Tydliggör användarberättelser

En sak som kan hjälpa till att stabilisera ditt teams sprintviktighet är att se till att användarberättelser är tydliga och lätta att förstå innan sprinten börjar. En användarberättelse är en snabb förklaring av en programvarufunktion som skrivs ur slutanvändarens perspektiv. De här användarberättelserna är ofta kopplade till punkter i en backlog. Det säkerställer att Scrum-teamet eller projektets teammedlemmar kan fokusera på arbetet de behöver göra, i stället för att ägna tid åt att leta efter intressenter för att få mer information. Det kan hjälpa till att öka hastigheten genom att fokusera teamets tid på det viktigaste arbetet.

Säkerställ enhetlighet

Om teamets hastighet är inkonsekvent kan det vara så att du ändrar för många variabler från sprint till sprint. Bytter du till exempel ut olika teammedlemmar från ditt utvecklingsteam? Sammansättningen av teamet kan påverka mängden arbete som teamet kan utföra. 

Här är några andra variabler som kan påverka din sprint-hastighet:

• Sprintlängd

• Ökning av story points

• Ändringar i processer

Fastställ en enhetlig definition av ”klart”

Det är viktigt att alla i teamet har en tydlig förståelse för vad det innebär för en användarberättelse att vara ”klar” eller slutförd. Det är en viktig aspekt av Scrum-ramverket som ofta används även i andra agila metoder. 

När ditt team har en tydlig definition av vad det innebär för en användarberättelse att vara slutförd kan de mer exakt uppskatta hur mycket arbete som är involverat i var och en. Det här leder i sin tur till mer exakta projektuppskattningar och i slutändan en mer exakt sprint-hastighet.

Håll en sprintåterblick

En av fördelarna med den agila metoden är att det är en iterativ utvecklingsprocess. Det innebär att det i slutet av varje sprint finns en möjlighet att reflektera över den senaste sprinten och se vad som gick bra och vad som inte gick bra. Ett möte för en sprintåterblick är avsett för just det – ett möte som är tillägnat att reflektera över den senaste sprinten och hur man kan förbättra sig inför nästa.

Målet är att ständigt förbättra sig. När ditt team itererar genom olika sprintar bör det tillämpa lärdomarna från tidigare sprintar i framtida sprintar. Det ger teamet möjlighet att ändra processer för att kontinuerligt förbättra sig.