Jimmy Janlén "Den Scrummande Konsulten"

Hur vet man att investeringen i utvecklingen matchar förväntningarna? Hur håller man koll på att projektet levererar ”i tid”? Hur mäter vi att mottagarna och beställarna är nöjda? Scrum påstår sig leverera mera funktionalitet av högre kvalitet som bättre matchar förväntningar och behov. Men hur mäter man och följer upp detta? Detta är andra delen av min artikelserie om tips, trix och verktyg för att mäta det agila projekts framgång och status.

Nedan listar jag några verktyg och mätvärden användbara för projektets produktägare och styrgrupp (Meta-Scrum) för bland annat release- och resursplanering. Men som alltid ska man ställa sig frågan varför man mäter något? Vad ska statistiken användas till? För vem är mätvärdet värdefullt? Historisk statistik på ett mätvärde i sig har inget värde, det är först när vi omsätter det till kunskap, insikt och handling som det ger oss något tillbaka. Fram tills dess är insamlandet och sammanställandet waste och kanske t.o.m. kontraproduktivt. Vi riskerar att belysa fel saker och kanske luras försöka bota symptom istället för det bakomliggandet problemet.

.

Release Plan vs. Effektmål

Vilka effektmål/affärsmål har vi satt upp med nästa Release? Vilka verksamhetsproblem hoppas vi lösa? Kommer nästa Release nå dessa mål? Ser prognostiserad tidplan ut att hålla?

Med en Release Burndown kan man enkelt prognostisera när scoopet för releasen är klar. Release Burndownen är också ett enkelt verktyg för att anpassa release-scoopet för att nå önskat release datum. Finns tydliga mätbara effektmål kan Produktägaren också avgöra om tillräckligt många av dessa blir uppfyllda.

Release Burndownen ger en tidig indikation på hur projektet går. Produktägare och styrgrupp kan avgöra om release-scoopet ska justeras, deadline flyttas fram eller om teamet behöver förstärkas med ytterligare resurser.

.

ROI kontra Kostnad

Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och  klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.

Att leverera enligt Scrum ger oss möjlighet att kontinuerligt försäkra oss om att teamet jobbar på just de saker som ger mest affärsvärde. Men det är inte bara en möjlighet utan även produktägarens skyldighet att se till att just så är fallet.

Utöver själva sprintens kostnad växer förvaltnings- och driftkostnader desto större och komplexare systemet blir. Denna aspekt återspeglas inte i illustrationen intill men bör finnas med som beslutsunderlag vid releaseplanering.

.

Rest/Släp

Hög rest-ratio (dvs. ration rest-tasks från föregående sprint/sprintar kontra ny funktionalitet) kan signalera många olika saker men framförallt en oförmåga att avsluta features och efter sprint demo ha en produkt som är ”klar”, dvs. redo för paketering och leverans. Ju fler features som är  ”work in progress” mellan sprintar desto mindre flexibilitet får produktägaren i sitt arbete med att prioritera produktbackloggen och desto mindre frihet över release-planeringen och större osäkerhet kring release-prognoser.

Vidare, om det alltid följer med rester från tidigare sprintar in i nästa sprint finns det en risk att man missa eventuella underliggande tekniska problem eller andra typer av hinder som gör att teamet har svårt att avsluta features. Inte nog med att produktägaren får allt mindre ”nytt” levererat per sprint, projektets sanna status blir allt svårare att utläsa.

.

Driftsättnings-/Packeteringsinsats

Hur stor är den faktiska insatsen att driftsätta (alt. paketera produkten) efter nästa Sprint Demo? Har projektet skjutit upp tasks rörande överlämning till förvaltning, dokumentation, acceptanstest, installationsscript, etc. betyder det inte att man är redo för leverans bara för att Release Burndownen närmar sig noll.

Så länge Scrum-projektet inte levererar en potentiellt installerbar/levererbar ny version av systemet/produkten varje sprint förlorar man den kontroll och flexibilitet som Scrum utlovar.

Skjuts vissa saker upp tills det ”är dags” måste detta förankras med produktägaren (och eventuellt styrgruppen) eftersom Release Burndownen inte längre berättar hela historien. (Alternativt lyfts dessa arbetsuppgifter in i produktbackloggen och görs till en del av releasen.)
.

Risk Burndown

Agila utvecklingsmetoder hanterar risk på daglig basis naturligt genom korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet, tät dialog osv. Trots detta kan det vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång. När projektet närmar sig release ska självklart denna risk helst nått noll.

Läs mer om Risk Burndown Chart i ett tidigare inlägg.

.

Project Success Sliders

Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.

Hur bra (eller dåligt) stakeholders och produktägare upplever att projektet går i jämförelse med uppsatta ”kriterier” bör följas upp löpande så att projektet så ofta som möjligt får en chans till feedback och möjlighet att agera och reagera om så krävs.

.

Project Success Sliders beskrevs först av Rob Thomsett i sin bok ”Radical Project Managment”. Nyligen släppte Mountain Goat Software ett snyggt och enkelt webb-verktyg för att skapa och ställa in project sliders – ”Project Success Calculator”.

.

Detta är del 2 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)