NOTICE: This blog post is in Danish
See this blog post in English using Google Translate

“Det kan man da ikke” vil de en del nok sige, men jeg vil våge at påstå at det kan man kan man da sagtens. Det går i alt sin simpelhed ud på at du kender forudsætningerne for at læse det enkelte burn down chart. Mange er “fanget” i den verden at et burn down chart skal udtrykke om vi har timer nok tilbage i sprintet til at kunne løse til timer vi har tilbage i sprint backlog’en. Det er i grunden også en meget godt betragtning af et sådan chart, men grunder det ikke i at man er lidt for bundet af den gamle stil?

“Time tracking is anti scrum” er et yndet citat fra Jeff Sutherland, én af de to fædre til Scrum.

Hvis vi hele tiden vil holde styr på hvor meget tid vi har tilbage så er det lige præcis “time tracking”, og hvem er det der kan bruge denne time tracking til noget? –Jeg tror hvis du spørger deltagerene i teamet, så syntes de sikkert det er besværlig hele tiden at kunne holde styr på hvor meget tid de har tilbage på de enkelte tasks, det vil hellere bruge tiden på at løse tasks. Jeg vil gætte på at det kun er den gamle “projektleder” rolle der syntes et burn down chart med tidsangivelse er interessant. Teamet er sikkert lige så tilfredse med en mindre detaljeret udgave, for de har jo hele tiden fingeren på pulsen og har en mavefornemmelse om de mener de stadig kan nå det, og teamets deltagere bliver sikkert også gladere hvis de slipper for hele tiden af skulle tage stilling til hvor lang tid de har tilbage på den enkelte task.

Faren ved at have et tidsbaseret burn down chart er også at man har en tendens til at blive fokuseret på tiderne i stedet for på opgaverne.
Min teori bygger på at man i stedet baserer sit burn-down-chart på antallet af tasks. Dette rejser spørgsmål som fx:

  • Hvordan kan alle tasks vægtes lige når de ikke har samme arbejdsbyrde.
  • Hvad hvis man løser alle de små tasks først, så får man jo en kraftig hældning i starten og en eget flad hældning derefter.
  • Hvad kan man bruge chart’et til når men ikke 100% kan stole på hældningen.

Teorien baserer sig på at man nok i gennemsnit får fordelt de små og store tasks jævnt hen over et sprint, der er ingen der har interesse i at forsøge at påvirke chart’et ved at tage de små tasks først, da chart’et er dit eget værktøj og du derved er i gang med at ødelægge det for dig selv.

Jeg tror dog man er nød til at fastsætte nogle retningslinier for hvor stor en enkelt task må være, for at man ikke få alt for stor afvigelse på en stor og en lille task. Mit bedste bud lige nu er at hvis man aftaler at en task maksimalt må være omkring 2 mandedage, men dette estimat skal blot være et gæt, ikke noget man har tænk dybere over, hvis det viser sig at det i virkeligheden er 2½ mandedag eller 3 mandedage så går det nok også.

Når man vil læse et sådan task-baseret burn down chart, har man så i baghovedet de forudsætninger man har aftalt. Fx at en task maksimalt er 2 mandedage, og at chart’et skal ses sammen med de tasks der ligger tilbage på sprint backlog’en.

Måden jeg vil bruge et sådan burn down chart på er ved at kigge på det for at få et ide om hvordan det går, og ser det kritisk ud på chart’et vil jeg på det daglige Scrum stille spørgsmålet til teamet “Kan vi stadig når det?”, og mener teamet at det kan vi godt så vil jeg ikke bekymre mig mere om det. Jeg vil så blive ved med at stille spørgmålet hver dag, så længe burn down chart’et, ser kritisk ud.

Hvis burn down chart’et derimod viser at der bliver rykket hurtigere en forventet, vil jeg på det daglige Scrum stille spørgsmålet “Kan vi nå mere end forventet?”.

Den svære spørgsmål er så hvornår er det kritisk og hvornår er vi foran, så man skal begynde at stille spørgsmålene – sagt på en anden måde, hvor meget skal vi afvige fra den forvende hældning før vi bør stille spørgsmålene. Mit bedste svar her må være at der her må være de samme betragtninger i spil, som hvis man brugte et tidsbaseret burn down chart, og i sidste ende er det nok helt op til teamets egne erfaringer hvornår man bør gøre noget – tage noget ud eller ind i sprintet.

Konklusionen her er altså at et burn down chart behøver ikke være tidsbaseret, det hele handler om at kende forudsætningerne for det enkelte burn down chart når du læser det.

Vi er i skrivende stund i gang med at afprøve min teori i det scrum team jeg til dagligt er en del af. Vi er ca. halvvejs i et 5 ugers sprint og endtil videre er min erfaring at det faktisk fungere udemærket, og folk er glade for ikke hele tiden at bliver slået i hovedet om at de skal huske at opdatere resterende tid på de enkelte tasks.