Agila mått är verktyg som används för att övervaka framsteg och framgångar inom ett agilt projektteam.
När dessa mätvärden definieras på ett ändamålsenligt sätt, ger de en djupare förståelse för teamets prestationer, kvalitetsarbete, effektivitet i testning och den övergripande effektiviteten, samt hur dessa aspekter utvecklas över tid.
Det huvudsakliga syftet med agila mått är att stödja teamen i att identifiera områden som behöver förbättras och att fatta informerade beslut baserade på data, vilket i sin tur leder till bättre produkter under projektets gång.
Många företag tenderar att definiera mätvärden som antingen är ytliga, eller bara råa tal som vackert ökar från vänster till höger. De kan se tilltalande ut i vissa dashboards, men oftast saknar de verkligt värde för teamet.
Deras avsikt är inte att på något sätt underlätta teamets arbete, utan snarare att generera rapporter för ledningen, som sedan resulterar i strategiska beslut. Tyvärr leder detta ofta till att teamet inte förstår bakgrunden till de fattade besluten.
För att anpassa sig till sådana bristfälliga mätvärden, manipulerar teamen ibland sina egna processer för att få resultaten att se bättre ut. Detta resulterar dock sällan i några faktiska förbättringar av teamets prestation.
Grundläggande indelning av mätvärden
Det finns flera sätt att kategorisera mätvärden. En grundläggande uppdelning är top-down och bottom-up.
➡️ Top-down innebär: Ledningen skapar mätvärden som teamet förväntas uppfylla, och målet är att passa in i de önskade intervallen. Oavsett om teamet uppskattar dessa mått eller inte, är det detta som kommer att spåras.
➡️ Bottom-up betyder: Teamet identifierar områden som behöver förbättras och fokuserar på dessa. Mätvärden definieras för att spåra teamets framsteg mot målen och visa ledningen exakt hur arbetet har förbättrats över tid.
Kriterier för ett bra mått
Vilka egenskaper ska ett bra mått ha, eller hur kan det beskrivas?
Den viktigaste egenskapen är att det ska driva beteendeförändring. Det innebär att varje gång resultatet av måttet granskas, ska det vara tydligt vilka förändringar som behöver göras inom teamet för att uppnå förbättringar.
Dessutom ska det vara enkelt att förstå. Om du inte kan förklara måttet på ett par korta meningar så att alla som behöver förstå det kan, då är det inte optimalt.
Ett bra mått är jämförbart över tid. Ta en ögonblicksbild av resultatet vid ett visst tillfälle och gör samma sak igen senare. Ställ dem sedan sida vid sida. Om resultaten inte kan jämföras direkt, bör måttet omprövas.
Slutligen, använd gärna förhållanden eller procentandelar istället för rena siffror när det är möjligt. ”10 nya öppna defekter under sprinten” säger inte så mycket. Det beror helt på om det normalt brukar vara en eller hundra.
Nedan följer exempel på mått som, enligt mig, uppfyller dessa kriterier. De är specifikt inriktade på agila team. Det finns tre huvudkategorier: prestation, kvalitet och moral.
Kategorisering av mått
Prestationsmätningar
Dessa mått syftar till att ge insikt i hur väl teamet lyckas hantera de uppgifter som de har åtagit sig i en sprint. De ger svar på frågor som om teamet tenderar att överbelasta sig, eller om överflyttade uppgifter är en återkommande företeelse.
Ur ett agilt prestationsperspektiv, bör teamet sträva efter att leverera det planerade sprintinnehållet som de har åtagit sig vid sprintens start.
Detta betyder inte att flexibilitet saknas under sprinten, utan att eventuella förändringar i uppgifter ska ske genom dialog, inte bara genom tillägg. Teamets kapacitet ökar inte bara för att nya uppgifter läggs till under sprintens gång.
Detta mått är viktigt för att uppmärksamma sådana scenarier och för att hjälpa alla i teamet att skydda den kapacitet de har för sprinten.
Detta bidrar till att bygga upp teamets tillförlitlighet och förutsägbarhet.
#1. Sprintkapacitet kontra levererade story points
Jämför sprintkapaciteten med de levererade story points (SP) över flera sprintar.
- Mindre variationer från sprint till sprint är acceptabla. Större svängningar indikerar att något inte stämmer.
- Den totala sprintkapaciteten beräknas genom att lägga ihop tillgängliga dagar för varje teammedlem. Till exempel, om ett team på 10 personer är tillgängliga under hela sprinten, är den totala kapaciteten 100.
Kontrollera sprintkapaciteten mot genomförda SP för varje sprint. Om teamet (under planeringen) åtar sig en betydligt högre mängd SP än de vanligtvis klarar av, bör denna risk uppmärksammas.
Målet bör vara att den totalt planerade SP:n är lika med eller lägre än den totala genomförda SP:n per sprint.
Det är möjligt att leverera fler SP än planerat, om teamet slutför alla planerade uppgifter och fortfarande har kapacitet att ta sig an ytterligare uppgifter.
- Om teamet upprepade gånger levererar färre SP än planerat, bör de justera planeringen och minska antalet SP som tas in i nästa sprint.
Verktyg som monday.com, Atlassian Jira eller Asana erbjuder smidiga lösningar för att spara och extrahera story points för varje uppgift i sprintarna. De kan även generera detta automatiskt efter varje sprintplanering.
#2. Burndown-diagram
Detta är ett mått som förmodligen de flesta scrumteam har någonstans på sin dashboard. Jag håller med om att det kan se ut som en onödig sak. Teamen ägnar det sällan någon uppmärksamhet. Chefer däremot kan använda det för att kontrollera hur uppgifterna ser ut från ett högre perspektiv, och se att de inte gör några större framsteg (då alla är öppna under hela sprinten).
Jag vill understryka att teamen själva bör granska sitt burndown-diagram. Om alla uppgifter är öppna under hela sprinten och stängs först på sista dagen, skapar det osäkerhet inom teamet och gällande möjligheterna att slutföra sprintmålen.
- Granska din sprintboard för avklarade uppgifter.
- Diskutera med teamet varför små uppgifter fortfarande är öppna, även om de startade tidigt i sprinten.
- Arbeta med teamet för att främja en kultur där man inte behåller uppgifter öppna längre än nödvändigt.
- Ett idealt burndown-diagram är ofta ett teoretiskt tillstånd. Men ju närmare vi kommer det, desto effektivare hanteras uppgifterna.
Agila hanteringsverktyg som Asana kan generera ett burndown-diagram automatiskt för varje sprint.
Källa: asana.com
#3. Slutförda sprintmål
Detta mått mäter hur stor andel av sprintmålen som har uppnåtts under varje sprint.
Sprintmålen dokumenteras separat, till exempel på en Confluence-sida/Jira för varje sprint. Det bör noteras om målen har uppnåtts eller inte under sprintens gång.
Även om teamet inte slutför alla uppgifter inom en sprint, kan de ändå ha uppnått sprintmålet (t.ex. om endast sido-uppgifter saknas).
Målet bör vara att uppnå 100% av sprintmålen varje sprint. Om så inte är fallet, bör man undersöka vad som hindrar teamet.
- Om det är för många parallella ämnen i varje sprint, minska antalet.
- Om för många ad hoc-uppgifter läggs till under sprinten, minska detta så att det inte påverkar de ursprungliga sprintmålen.
- Om sprintmålen är för stora eller svåra, gör dem enklare. Det är kontraproduktivt att sätta stora sprintmål samtidigt som de ändå inte uppnås i slutet av sprinten.
Mått för kodkvalitet
Detta avsnitt fokuserar på att mäta kvaliteten på koden över tid. Det är ett stöd för att upprätthålla sunda utvecklingsprocesser och minska tiden som läggs på att lösa problem. Det minskar även den tid som utvecklare inte kan jobba under utveckling och testaktiviteter.
Källa: azuredevopslabs.com
#1. Automatiserade tester
Uppmana utvecklarna att skapa automatiserade enhetstester för varje förändring de gör.
- Mät kodtäckningen med automatiserade tester – använd Azure Pipelines eller SonarCloud för att genomföra testerna. Sikta på 85% täckning. Över 90% är inte särskilt effektivt.
- Se till att automatiserade enhetstester ingår i definitionen av ”klart” för nya uppgifter.
- Arbeta ikapp med gamla testtäckningar genom att skapa tekniska skulduppgifter i backloggen.
#2. Kodkomplexitet
Utvärdera onödiga komplikationer som uppstår i koden över tid och åtgärda dem genom tekniska skulduppgifter. Eller helst, förhindra att de uppstår helt och hållet.
Definiera kodstandarder och riktlinjer som utvecklarna kan följa. Se till att de håller sig till dessa regler för att minimera den onödiga ökningen av kodkomplexitet. Uppdatera riktlinjerna regelbundet baserat på teamets erfarenheter.
Identifiera ”kodlukter” – indikatorer på potentiella problem i koden, som duplicerad kod, långa metoder och oanvända variabler.
Genomför kollegiala kodgranskningar för att säkerställa att kodstandarder tillämpas på ny kod.
Använd verktyg som Azure Ado eller SonarCloud dashboards och rapporter för att identifiera kodproblem.
#3. Manuella steg i distributionen
Följ hur många manuella steg som teamet behöver utföra för att distribuera kod till test- eller produktionsmiljöer.
- Målet ska vara att eliminera alla manuella steg över tid.
- Skapa tekniska skulduppgifter om det behövs för att flytta distributions- och release-pipelinen mot en fullständig automatiseringsfärdplan. Minska gradvis de manuella stegen i processerna under varje sprint.
Mått för moral
Dessa mått mäter hur teamet trivs med sitt arbete och de processer som de dagligen använder sig av.
#1. Genomförande av åtgärder från sprint retrospektiv
Följ hur många åtgärder som faktiskt genomfördes i nästa sprint.
- Scrum Master ska samla resultaten från retrospektiva möten på teamets sida för att spåra överenskomna åtgärder.
- Teamet bör sedan regelbundet följa upp framstegen.
- Projektledningen kan sedan granska huruvida åtgärdspunkterna går framåt eller vad som hindrar teamet från att slutföra dem. Därefter justeras miljön så att teamet kan gå vidare med de överenskomna åtgärderna.
Minst 33% eller 1 (beroende på vilket som är högre) av åtgärderna från föregående sprint bör hanteras i nästa sprint.
Om det är mindre än så, behöver förändringar göras för att teamet ska kunna genomföra de förbättringar som de har enats om.
Projektledningsverktyg erbjuder färdiga mallar för retrospektiva sprintaktiviteter. Här är ett exempel från monday.com:
Källa: monday.com
#2. Teamsamarbete
Använd parprogrammering.
- Skapa naturliga par för varje uppgift för att främja samarbete, kunskapsdelning och framgång. Skapa deluppgifter som ägs av olika teammedlemmar under varje uppgift.
Följ initiativet till kollegial kodgranskning.
- Uppmuntra kollegor att ta initiativ till att granska varandras uppgifter.
Detta mått kan hämtas från monday.com/Asana/Jira-tavlan utifrån deluppgifterna.
Minst 50% av uppgifterna i sprinten bör delas av teammedlemmarna. Om det är lägre, bör orsaken utredas och åtgärder vidtas vid behov.
För frivilliga kollegiala granskningar, håll koll på uppgifterna med dedikerade deluppgifter. I början kan 20% av de kodgranskade uppgifterna vara en bra start. Gradvis bör teamet uppmuntras att arbeta mer kollaborativt och öka detta till 50% av koduppgifterna per sprint som mål.
#3. Teknisk skuld kontra nya funktionsuppgifter
Källa: atlassian.com
Att ge teamet möjlighet att lösa sina egna skulduppgifter ökar trivseln i teamet.
- Tvärtom kommer ackumuleringen av tekniska skuldproblem utan en plan för att lösa dem gradvis att minska teamets motivation över tid. Dessutom kommer lösningen att bli alltmer instabil, komplicerad och svår att åtgärda utan omfattande omarbetning.
Teamet är bäst informerat om vilka delar av lösningen som inte fungerar så bra, även om intressenter eller slutanvändare inte ser det. Sådana uppgifter har störst inverkan på utvecklingsteamet själva. För intressenterna kan de vara osynliga. Det är därför det är så viktigt att ge teamet chansen att arbeta med uppgifter som hjälper dem att förbättra utvecklingsaktiviteterna.
Målet är att övervaka hur många tekniska skulduppgifter som åtgärdas över tid och om backloggen med sådana uppgifter växer eller inte.
Teamet kan tagga uppgifter som TechDebt i backloggen och prioritera dem själva, så att de hamnar högt upp på listan och väljs ut under sprintarna.
Beroende på vilket stadie projektet befinner sig i och hur mycket teknisk skuld som identifierats i backloggen, bör man se till att TechDebt-backloggen inte växer med mer än 10% från sprint till sprint.
Prioritera tekniska skulduppgifter och inkludera dem i sprintarna, så att teamet får arbeta med dem 10-20% av tiden varje sprint.
Avslutande tankar
Varje projekt kommer så småningom att behöva vissa mått, antingen för att ledningen kräver det, eller för att teamet vill mäta sina egna framgångar.
Det bästa man kan göra är att börja bygga upp ett bibliotek med mått som är redo att användas. Ju tidigare desto bättre. Och när man gör det, bör man alltid välja beteendeförändrande mått framför allt annat.
Slutligen, var uppmärksam på eventuella ohälsosamma processer som kan förstöra sprinten.