Scrum - rapportering

Å måle fremdriften til et Scrum team ligner på det å kartlegge posisjonen til et fly.

Bilde av flyVi vil gjerne fly vårt prosjekt i en rett linje fra A til B, men det skjer sjelden. Krav endres og av til gjør vi feil når vi vil finne ut hvor vi er. Som et fly er vi kanskje ute av kurs mesteparten av turen, men som et fly korrigerer vi også kursen konstant for å sikre at vi kommer frem til B.

Måle fremdrift

Underveis og spesielt ved avslutningen av hver sprint, vil vi vite hvordan vi ligger an i forhold til målet.

Det er to “krefter” som påvirker fremdriften vår:

  1. Mengden arbeid teamet har utført
  2. Endringer i opprinnelig omfang

Hva tas med?

Den viktigste regelen er at det er bare potensielt leveringsklar funksjonalitet som tas med i rapportene. Komplett betyr ikke ”det er kodet, men ikke testet” eller ”det er kodet, men ikke integrert med resten ennå”. Komplett betyr kode som er godt skrevet, godt bygd opp, sjekket inn, som er i henhold til kodestandarder og som har passert alle tester.

Å forsøke å telle med halvferdig arbeid gir oss bare utfordringer. Når vi opplever halvferdig arbeid i sprinten er det viktig å lære av det:

Kanskje oppgaven var underestimert? I tilfelle hva hadde vi glemt?
Kanskje vi hadde tatt for mye med i sprinten? I tilfelle må vi ta med oss den lærdommen når vi skal planlegge neste sprint.

Release Burndown diagram

Figuren nedenfor viser et Release Burndown diagram:

Figur som voser release bunrdown diagram

Diagrammet viser mengde arbeid som til enhver tid gjenstår før teamet er i mål.

Det er selvfølgelig svært lite sannsynlig at et team arbeider så jevnt som diagrammet viser. Et mer reelt diagram kan se slik ut:

Illustrasjon av diagram

I første sprint var teamets hastighet omtrent som estimert, muligens noe foran. I andre sprint har teamet mer arbeid igjen etter iterasjonen er gjennomført enn da de begynte. Her må noe ha gått senere enn estimert eller noe er blitt lagt til av funksjonalitet. I sprint tre og fire fortsetter teamet med grei hastighet.

Skille ut endringer i omfang

I produktutviklingsprosjekt er det ofte viktig å synliggjøre det hvis omfanget har blitt endret underveis: Det skumle ”creeping scope”-spøkelset.

Hvis omfanget utvides og vi bruker et Release Burndown diagram for å visualisere fremdriften, vil det se ut som hastigheten til teamet har gått kraftig ned. For å skille fremdriften til teamet fra endring i omfang, kan vi bruke et Release Burndown stolpediagram. Det er i utgangspunktet helt likt, men vist med stolper:

Illustrasjon av diagram

Fra stolpediagrammet ser vi at vi i de tre første sprintene har tatt unna greit med arbeid, men hva skjer i den fjerde iterasjonen? Vi håpet på utviklingen indikert av den stiplede linja.

Det kan være at noe gjorde at hastigheten gikk kraftig ned. I det tilfelle er diagrammet ovenfor riktig. Men hvis grunnen er at det er lagt til funksjonalitet slik at omfanget har økt, kan det vises slik i stedet:

Illustrasjon av diagram

I fjerde sprint er det lagt til funksjonalitet som ikke var med i det opprinnelige omfanget. Det viser vi ved å legge det økte omfanget under x-aksen. Når vi gjør det er det lettere å se at farten har vært god, men siden vi har lagt til krav har omfanget økt.

Hvis opprinnelig omfang reduseres, kan vi vise det slik:

Illustrasjon av diagram
I andre sprint legges det til omfang. Gjennom sprint tre og fire bruker vi ny kunnskap og krav estimeres på nytt. I sprint fem, tar vi bort litt av det opprinnelige omfanget.

Hva er det som gjør at stolpene forandrer seg?

  • Når et krav er komplett, senkes toppen på stolpen
  • Når et krav estimeres på nytt, beveger toppen på stolpen seg opp eller ned
  • Når omfanget øker, senkes bunnen på stolpen
  • Når omfanget reduseres, beveger bunnen på stolpen seg opp

Måle fremdrift for en sprint

Fremdriften for en sprint måles på samme måte som for en release. X-aksen viser da dager i stedet for sprinter, mens Y-aksen viser timer.
 
Det kan være greit å la oppgaveoversikten være indikatoren for fremdrift og gjerne vise dette på en tavle:

Illustrasjon av oppslagstavle

Etter hvert som vi arbeider med de ulike oppgavene flytter vi dem mot høyre i diagrammet. Den enkleste måten å realisere dette på, er å bruke kartotekkort, en god, gammeldags korktavle og noen tegnestifter.

Illustrasjon av vår oppslagstavle