Et alternativt Burndown Chart

Publisert den Skrevet i Agile, Burndown Chart, Metodikk, Planlegging, Story Points

Et av de mest brukte verktøy vi har i Agile er det Burndown Chart. Det gir oss en god oversikt over hvor mye jobb er igjen i vårt prosjekt på en veldig enkel måte. Det er faktisk at det er så enkelt, det som gjør det nyttig. Chartet en relativt lett å holde oppdatert og gir oss akkurat den mengde informasjon vi trenger til å holde styr på tid og arbeid. Selv om i de fleste tilfeller funker det utmerket, av og til kan det hende at dets enkelhet maskerer potensielle avvik i vårt prosjekt. Dette ser vi særling når ekstra jobb er lagt til.

Et simpelt eksempel: vi har et lag som skulle i utgangspunktet ha klart å gjøre ferdig 20 Story Points i den sprint det er nå nettopp ferdig med. Men i den siste revisjon av det Burndown Chart ser vi at de har klart bare 5 Story Points.  Den første ting vi lurer på er om laget har feilet å levere etter forventinger, eller med andre ord, om at de er blitt tregere. Men, kan det hende at de har levert som vanlig, men at det som skjer er at ekstra jobb ble lagt til?

Vi må ikke glemme at Burndown Chart er et verktøy som skal vises til prosjektets stakeholders, det vil si, folk som ikke har tilgang til den interne informasjon vi har. Derfor må vi ikke bare forvente at de som ser på chartet vet like mye som vi vet.

Det er essensiell og skikkelig viktig å finne ut grunn til avvik, men også til å bruke de riktige verktøy.

Vi vil presentere et alternativt Burndown Chart, som er et chart vi bruker ved siden av den tradisjonelle Burndown Chart, ikke som en erstatning.

 

 

I dette chartet, Y-aksen representerer hvor mye jobb er igjen. Vi bruker Story Points, så på chartet ser vi at prosjektet begynte med 100 Story Points da vi startet med Sprint 1. På X-aksen ser vi hvor mange Sprints skal vi bruke for å gjøre jobben ferdig.

Hvis vi følger chartet, ser vi at på den første Spring klarte laget å gjøre ferdig 20 Story Points. Det vil si at når vi begynner med Sprint 2, har vi 80 Story Points igjen. Det samme skjer på Sprint 3, der vi begynner med 60 Story Points etter at laget klarte igjen 20 Story Points på Sprint 2.

Men før vi begynte med Sprint 4, la Product Owner 10 Story Points til, som ikke var planlagte da vi begynte med prosjektet. Istedenfor å legge disse 10 nye Story Points til gjenstående arbeid, viser vi disse for seg under den opprinnelig kolonne på Sprint 4. Det vi ser i det nye chart, er at på Sprint 4 har vi 50 Story Points av arbeid igjen: de opprinnelig 40 pluss de nye 10.

Men hva som skjer hvis Product Owner fjerner jobb fra de gjenstående Story Points?

 

 

La oss si at Product Owner har fjernet 5 Story Points fra fremtidige arbeid. Måten vi må representere det, er med å trekke fra den nederste delen i kolonner. Akkurat på samme måte da vi la til ekstra Story Points.

Da er spørsmål: hvordan kan vi forutse hvor mange ekstra Sprints kommer vi til å bruke for å håndtere det nye ekstra arbeid?

 

 

Man kan forutsi hvor mange ekstra Sprints trenger vi med å tegne to trendlinjer: den første på toppen av kolonner for å måle gjenstående Story Points. Den andre på bunn av kolonnene der vi inkluderer endringer vi har hatt. I vårt opprinnelige eksempel ser vi at vi trenger sånn cirka en Sprint til for å være ferdig med prosjektet, inkludert avvikene vi har hatt.

Hva synes du om dette alternativt Chartet? Tror du det kan være nyttige å ta i bruk? Vi vil gjerne høre fra deres erfaring med like verktøy!