Släpande velocitet - det bästa från Kanban och Scrum

Ett av det absolut vanligaste verktyget för att mäta resultat inom ett agilt utvecklingsteam är velocitet. Denna räknas ut genom att man lägger ihop poängen (story points) för de uppgifter (user stories) som teamet avslutade under sprinten. Detta inkluderar vanligtvis utveckling, kodgranskning, testning och acceptans.

Under sprinten mäter man enkelt progressen genom till exempel en burndown-graf där man varje dag plottar upp en ny punkt som motsvarar kvarvarande poäng efter att dagens fullbordade poäng räknats bort. Resultatet blir en nedåtgående graf som förhoppningsvis når ner till noll vid slutet av sprinten. Jag har använt burndown-grafer i många team och det har varit framgångsrikt i de flesta fallen. Trots det finns det vissa nackdelar med att tillämpa en allt-eller-inget-approach för story points.

Låt oss föreställa oss ett scenario där vi är två dagar ifrån slutet på sprinten. Det finns fortfarande uppgifter kvar att göra på boarden och en utvecklare har precis avslutat sin uppgift och vill plocka en ny. Det finns två alternativ: antingen väljer hon den som ligger överst eftersom den är viktigast eller så går hon längre ner på listan för att hitta en uppgift som hon vet kommer att hinnas utvecklas, granskas och testas inom två dagar. Om hon väljer den översta uppgiften kommer troligtvis inga poäng att tilldelas sprinten eftersom den inte kommer att hinnas fullföljas innan sprinten tar slut. Den mindre uppgiften däremot kommer att avslutas och belönas med poäng i sprinten.

Som produktägare eller beställare skulle jag vilja att utvecklaren väljer den viktigaste uppgiften även om den kanske inte hinns med under sprinten och oavsett hur många poäng den ger. Man säger ofta att varje sprint ska ha en isolerad leverans och ett satt mål men verkligheten är tyvärr inte lika enkel: ofta brukar viktiga funktioner kräva flera sprintar innan beställarna är helt nöjda. Så hur kan vi upprätthålla utvecklingstakten utan att påverka velociteten negativt?

Utmaningarna med att sätta tydliga avgränsningar för vad varje sprint ska leverera är att det krävs mycket planering på en detaljerad nivå för att bryta ner uppgifterna till små beståndsdelar samtidigt som det krävs av teammedlemmarna att de kan utföra alla delar av uppgiften. I början av varje sprint finns ju inget att testa och i slutet av sprinten ska man helst inte påbörja något nytt eftersom det inte kommer att kunna avslutas i tid. Detta innebär att testare förväntas utveckla i början av sprinten och utvecklare förväntas testa i slutet av sprinten. Vilket låter väldigt fint på pappret men inte blir lika effektivt i praktiken. Detta dilemma leder till att många utvecklingsteam överger sprintplaneringarna helt och hållet och övergår till Kanban. Vilket i sin tur gör beställarna frustrerade eftersom de förlorar uppfattningen om när saker kan förväntas bli klara.

För att bättre återspegla kapaciteten inom ett utvecklingsteam tog jag fram en variant av velocitet som förebygger nedgångarna i början och slutet av sprintarna samtidigt som den uppmuntrar till att man drar uppgifter från vänster till höger på boarden. I det som jag väljer att kalla för släpande velocitet (trailing velocity) har varje steg i processen ett värde i sprintens slutgiltiga resultat. Nedanstående är ett förslag och kan självklart anpassas efter teamets arbetssätt:

Velocitet = 25% av allt under utveckling + 50% av allt under kodgranskning + 75% av allt under testning + 100% av allt som är accepterat och avslutat

Låt oss ta ett exempel: när en sprint avslutades återstod uppgifter motsvarande 9 poäng i utvecklingskolumnen, 9 poäng i kodgranskning, 2 poäng under testning och 27 poäng under avslutat. Med det traditionella tänket skulle därmed velociteten bli de sista 27 poängen. Den släpande velociteten däremot är 0,25 x 9 + 0,50 x 9 + 0,75 x 2 + 1,00 x 27 = 35,25 poäng. Detta betyder att ytterligare 8 poäng (”släpet”) har lagts till de avslutade 27 poängen.

Det finns flera fördelar med en släpande velocitet. Den uppmuntrar till det som lockar många till att köra Kanban — att man upprätthåller ett flöde på boarden där man alltid plockar det som är viktigast — samtidigt som det behåller fördelarna med sprintplaneringarna då beställare och Scrum-teamet tillsammans sätter målen och förväntningarna för sprinten. Slutresultatet blir teammedlemmar som blir nöjdare eftersom det alltid finns något relevant att göra genom hela sprinten samtidigt som beställarna blir glada över att teamet alltid fokuserar på det viktigaste oavsett hur många poäng det råkar generera.