Scrum Guide | 34. Hastighet i Scrum – Utvecklingsteamets hastighet

Velocity i Scrum hjälper dig att bestämma den hastighet med vilken Scrum-teamet slutför uppgifter. Vi kan definiera det som det genomsnittliga antalet Story Points som slutförs under en Sprint. Velocity kan också uppskatta varaktigheten av ett projekt baserat på redan slutfört arbete. Men detta är endast meningsfullt för ett moget team som arbetar i en jämn och stabil takt. Ta en titt på vad Velocity är och hur du får det att fungera bäst för dig!

Velocity i Scrum – innehållsförteckning:

1. Velocity i Scrum – Introduktion
2. Aktuell och planerad velocity
3. Svårigheter och risker kopplade till Velocity i Scrum
4. Sammanfattning

Velocity i Scrum – Introduktion

Velocity är en valfri men populär metod för att mäta takten hos ett Scrum-team. Detta beror på att en korrekt uppskattad Velocity möjliggör att förutsäga, i rimlig utsträckning, den tid som behövs för att slutföra ett projekt. Det är dock ett mått som endast kan tillämpas på ett givet utvecklingsteam, som kommer att utföra uppgifter som det har “värderat” själv med hjälp av en bekant enhet, såsom Story Points, till exempel.

Velocity för utvecklingsteamet presenteras oftast i form av ett Velocity-diagram. På X-axeln markeras på varandra följande Sprints. På Y-axeln, å sin sida, hittar vi antalet Story Points eller andra motsvarande enheter som slutfördes under en given Sprint. Med Velocity-diagrammet får Scrum-teamet en tydlig översikt över förändringar i takten i sitt arbete. Om linjen som markeras på diagrammet stiger, betyder det att teamet optimerar sin effektivitet eller minskar värdet av Story Points. Både Scrum Master och Product Owner bör därför noggrant följa linjen som visar teamets Velocity.

Aktuell och planerad velocity

Den aktuella Velocity för utvecklingsteamet beskriver takten i arbetet under den slutförda Sprinten och beräknas i slutet av varje Sprint. Den tar värdet av summan av Story Points för alla slutförda User Stories. Den aktuella Velocity för utvecklingsteamet gör det möjligt att planera och uppskatta med viss sannolikhet takten för framtida uppgifter.

Den planerade Velocity, å sin sida, uppskattas baserat på ett genomsnittligt värde av den aktuella Velocity. Det kräver antagandet om ingen förändring i utvecklingsteamet. Det är ett viktigt internt verktyg för utvecklingsteamet, som, baserat på det, kan bedöma om samarbetet i teamet fungerar bra och om takten i arbetet upprätthålls.

Planerad Velocity möjliggör också för Product Owner att förutsäga genomförandetiden för väldefinierade User Stories som är schemalagda för genomförande i kommande Sprints. Detta möjliggör mer effektiv vård av Product Backlog, vilket vi skrev om i denna artikel. Men praktiken att tillämpa planerad Velocity för att uppskatta projektets varaktighet är inte så enkel.

Svårigheter och risker kopplade till Velocity i Scrum

Velocity i Scrum ges ofta för mycket betydelse utan att ta hänsyn till följande faktorer:

• uppskatta större helheter eller hela projektet – medan utvecklingsteamet kan uppskatta antalet Story Points som ska tilldelas en specifik uppgift, är det mycket svårt eller omöjligt att beskriva större helheter för framtida genomförande i dessa enheter
• förändringar i projektet – varje förändring i projektet innebär potentiellt en förändring i antalet Story Points som behövs för att uppnå produktmålet. Det kan också vara så att uppgifter som redan har slutförts behöver modifieras eller till och med inte användas i den slutliga versionen av produkten
• oförutsedda händelser – att förutsäga takten för framtida projekt baserat på redan slutförda, det vill säga att översätta aktuell Velocity till planerad Velocity, kan resultera i exakta uppskattningar. Men varje projekt har sina egenheter och en exakt förutsägelse baserad på historik är vanligtvis omöjlig.

Sammanfattning

Att använda Velocity som en metrisk för att utvärdera effektiviteten hos utvecklingsteamet kan orsaka att dess tillförlitlighet försämras. Det kan också försämra kvaliteten på uppskattningarna, vilket vi skrev om mer detaljerat i denna artikel. För att få de bästa möjliga resultaten i metrik kan utvecklingsteamet överdriva arbetsintensiteten för uppgifter för att öka Velocity. Detta är skadligt eftersom teamet i sig då förlorar värdefull information för att göra förbättringar och planera sina uppgifter mer noggrant.

Velocity i Scrum är främst användbar som ett internt mått som används av utvecklingsteamet för att utvärdera takten i sitt arbete. Detta beror på att det gör det möjligt att bestämma hur många uppgifter det är kapabelt att slutföra under en enda Sprint.

Velocity i händerna på Product Owner blir ett användbart verktyg för att uppskatta tidsfristen för större uppgifter.

Men de största riskerna är kopplade till att använda Velocity som en metrisk för att utvärdera utvecklingsteamet. Detta beror på att det kan leda till en sänkning av dess trovärdighet och till och med en avsiktlig överdrift av dess värde för att förbättra den externa utvärderingen av Scrum-teamets arbete.

Om du gillar vårt innehåll, gå med i vår aktiva gemenskap av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.