A burndown chart az egyik legegyszerűbb és legsokoldalúbban alkalmazható agile módszertani támogató eszköz.

Egyetlen célja, hogy bárki, aki a csapat közelébe ér, 20 mp alatt tudjon tájékozódni arról, hogy mi történik a csapattal, hol tartanak a feladataikkal egy adott sprintben, milyen tempóban haladnak, mikorra fognak végezni, adott esetben mennyi az a feladat mennyiség ami várhatóan csúszni fog, vagy amennyivel korábban fognak végezni.

Ehhez képest a burndown chart karbantartásra és működtetése filléres tétel.

Ahhoz, hogy burndown chartot lehessen optimálisan üzemeltetni, pár előfeltételt be kell tartani:

• A csapat összetétele ne változzon
• Fix Sprintekben dolgozzunk
• User sztorikra legyenek bontva a feladatok
• Legyen egy white board ahol nyilvánosan és fizikailag vezetni lehet a burndown chartot
• Tartsák a napi koordinációt (standup

Az X tengelyen mindig a sprint napjai láthatók. Ha kéthetes sprintekben dolgozunk akkor 10 rovátka kell, az Y tengelyen a bevállalt feladat mennyiség, lehetőség szerint sztori pontban. Ha becsült órákban akarjuk vezetni, az is megengedett, sőt sok helyen mindkét mértékegységet egyszerre alkalmazzák.

Első lépésként be kell húzni az ideális vonalat ami a becsült órák vagy sztori pontok tetejétől az utolsó napig tartó egyenes. Az ideális görbéhez képest lépcsőzetes módon fog csökkenni a még hátralévő feladatok mennyisége. Azaz így fog látszani a csapat haladása.

Egy tipikus példa:

Első nap mondjuk nem fejeztünk be semmit még, második nap megcsinálunk egy feladatot de ezzel még az ideális vonal fölött vagyunk (az ideális vonal és az a feletti rész közötti távolság az a feladatmennyiség, ami, jelenlegi tudásunk alapján,  kétséges, hogy elkészül).

Ha a harmadik nap a csapat befejez több feladatot, és ezzel betérnek az ideális vonal alá, akkor megint a két vonal közötti távolság fogja emegadmondani, hogy mi az a munkamennyiség, ami még, jelenlegi tudásunk alapján, bele fog férni a sprintbe.

Miket lehet leolvasni a Burndown chartrol? Lásd ábra és a 13 pont.

1. szumma becsült óra a sprintben vagy szumma story point (ha azt használják)
2. munka napokban megadva az időtengely
3. pont olyan osztásban, ahogy a csapat a sprintben megegyezett. esetünkben 10 munkanap (két  hét)
4. 4 ideális egyenes.ehhez képest ha felette vagyunk késni fogunk ha alatta, akkor hamarabb végzünk
5. a tényleges burndown vonal, annyival megy le, amennyit az adott napon a csapat a definition of done szerint befejezett
6. ha vízszintes (0 meredekkségű) vonalat látunk mindig vizsgáljuk meg, kérdezéses módszerrel, annak okát:
   1. előkészítés?
   2. kezdeti nehézségek?
   3. túl sok párhuzamosított feladat?
   4. a csapattal történt valami?
   5. az erőforráshoz piszkált hozzá valaki?
7. mint 6. pont csak itt a  korábbi erős beszakadás arra is okot adhat, hogy hirtelen sok mindent kellett pl.:
   1. integrálni
   2. tesztelni
   3. bugfixelni
   4. stabilizálni
8. a csapat neve
9. a csapat melyik sprintje van éppen folyamatban
10. mikor lesz a csapat demója. minden demó nyilvános!
11. mikor fejezi be a csapat a kódolást, és kezdi el a felkészülést a demóra?
12. az adott sprint célja. mi az az üzleti logikai egység amit teljesíteni kell a sprintben
13. ki a perszóna, aki a központi szereplője a sprint célnak

Például látni lehet, hogy hányszor vannak vízszintes szakaszok a burndown chartban. Tehát olyan napok, amikor valójában nem sikerült feladatokat befejezni. Fejlesztési tevékenység folyt ugyan, de Done-ba épp nem került semmilyen item.

Burndown chart csak akkor mehet lefelé ha egy item a definition of done szerint, “kész” állapotba kerülhetett!

Ha már van néhány napnyi mérésünk, akkor előre lehet vetíteni hogy hány nappal a tervezett előtt vagy után érkeznénk a célba.

Ha a sprint eredetileg kitűzött vége után érkeznénk a célba, tilos a sprintet meghosszabbítani! Ilyenkor a product owner feladata meghatározni azt, hogy mik azok sztorik vagy backlog itemek, amiktől el lehet tekinteni a sprintben egészen addig, ameddig nem nyerünk valahol időt. Tehát mindig vissza kell állítani a csapatot az ideális ívre, még akkor is, ha ez feladatok elvételével jár.

Az, hogy egy feladatot a sprintből kihúzunk, nem azt jelenti, hogy a feladatot egészében kihúztuk a teljesítésből! Csak azt jelenti, hogy az adott sprintbe nem fér bele a szóban forgó feladat. Ha a prioritások nem változtak, akkor a következő sprintet nyugodtan kezdhetjük a kimaradt feladattal is. Ennek azonban minden alkalommal tudatos döntésnk kell lennie, és nem lehet automatizmus!

Ha az extrapolációs vonalból az látszik, hogy hamarabb végez a csapat, az is látszani fog, hogy mennyivel. Ekkor a product ownerrel közösen dönthetnek a nyert idő felhasználásáról. Költhetik: tanulásra, oktatásra, tervezésre, technológiai adósság ledolgozására, kutatásra. További fejlesztési feladatokat csak akkor húzzunk be a nyert idő terhére, ha az mindenképp muszáj.

Le lehet még olvasni a vízszintes vonalaknak a számát is. Ha két egymás utáni nap vízszintes vonalat húz a csapat, akkor a product ownernek azonnal be kell avatkoznia, és fel kell tennie kérdéseket, hogy miért van az, hogy még nem tudtunk befejezni semmit a két nap alatt.

A burndown chart, ha kedvezőtlen képet mutat, soha semmilyen körülmények között nem használható arra, hogy a csapatot bántsa a menedzsment! Az egyetlen egészséges lépés, hogy a chart alapján érdeklődő kérdéseket tegyenek fel, amire a csapat vagy a scrum master tud válaszolni.

A menedzsment mindig fogadja megértéssel és köszönettel a rossz híreket is! Így elérhető, hogy a csapat megbízzon a menedzsmentben annyira, hogy mindig még idejekorán felvállalják a hibákat, és ezzel megadják a menedzsmentnek a legfontosabbat: lehetőséget a célzott és időben történő beavatkozásra.