Scrum Útmutató | 31. Hogyan készítsünk és értelmezzünk egy Burndown Diagramot?

Ezért a digitális Burndown Chart készítési módszerek sokkal elterjedtebbek. Számos eszköz, amely a feladatok munkájának rögzítésére szolgál a Csapat tagjai között, automatikus Burndown Chart készítési lehetőséggel rendelkezik. Ezután a Fejlesztőnek csak annyit kell tennie, hogy megjelöli egy adott termékfunkció munkájának kezdetét és végét, és hozzájárulása a Burndown Charton tükröződik.

A megfelelő eszközökkel szabadon skálázhatod a chartot. Ez betekintést nyújt a munkába nemcsak egy adott Sprint szintjén, hanem egy negyedév vagy az egész projekt szintjén is.

Fontos tényező, amit figyelembe kell venni egy Burndown Chart készítésére szolgáló eszköz kiválasztásakor, az elérhetősége minden Scrum Csapat tag számára. A Burndown Chart láthatósága az egész Fejlesztő Csapat számára kulcsfontosságú motiváló tényező. Ugyanolyan fontos a napi pillantás a hátralévő munkát mutató vonalra. A Daily Scrum során a burndownról való beszélgetés arra készteti a Fejlesztőket, hogy gondolkodjanak a munkájuk módjairól és a Termék aktuális állapotáról.

Ki felelős a Burndown Chartért?

A Burndown Chart tulajdonjogának kérdése némileg ellentmondásos. Egyrészt a Scrum Masteré kell, hogy legyen, mert ez egy eszköz annak biztosítására, hogy a Csapat hatékonyan és a tervek szerint dolgozik. Másrészt a Termék Tulajdonos kezében kell maradnia, mert ez tükrözi a Vásárlónak kommunikált Termék Cél felé haladást. Sőt, egy harmadik fél, aki igényt tarthat a tulajdonjogára, a Fejlesztő Csapat, mivel a chart a belső eszközeként működik.

A Burndown Chart alapvető mutató a Fejlesztő Csapat hatékonyságának értékelésére, és minden Scrum Csapat tagja által elfogadottá válik. Ezért a transzparencia és az elérhetőség kulcsfontosságú. Azonban az igazi célja, hogy szolgálja a Csapatot. Erősítenie kell az önszerveződést, javítania kell a motivációt, és valós képet kell adnia a rábízott feladatok állapotáról. Ezért elméletileg a Fejlesztő Csapat minden tagja frissítheti a Burndown Chartot.

Gyakorlatban azonban a Burndown Chart frissítésének feladata általában a Scrum Masterre hárul. Ez különösen akkor történik, amikor új Fejlesztő Csapattal kezd dolgozni, amikor a Csapat Sebessége még változó és nehezen becsülhető. Ennek ellenére ajánlott ezt a feladatot az egyik Fejlesztőre bízni. Végül is a chartnak őszinte és belső mérést kell nyújtania a munka előrehaladásáról, ahogyan azt maguk a Fejlesztők ítélik meg.

Hogyan értelmezzünk egy Burndown Chartot?

A Burndown Chart megjelenését részletesen leírtuk egy korábbi cikkben. Itt csak emlékeztetni szeretnénk, hogy az X-tengely a hátralévő időt mutatja a munka befejezéséhez. Másrészt az Y-tengely a hátralévő munkamennyiséget mutatja.

Valódi és ideális Burndown Chart

A Burndown Chart értelmezéséhez a kulcsfontosságú tényező nemcsak a rendszeres valódi “égés” ábrázolása, azaz a Fejlesztő Csapat által végzett feladatok végrehajtása. Ugyanolyan fontos a kép szempontjából az ideális égési vonal csökkenésének (irányelv) összehasonlítása.

Az ideális égési vonal és a Burndown Charton megjelölt valós csökkenés összehasonlításával két nagyon fontos paraméter értékelhető. Először is, hogy lássuk, folytatódik-e a munka a jelenlegi ütemben, a Fejlesztő Csapat időben eléri-e a Sprint Célját vagy a Termék Célját. Másodszor, hogy képet kapjunk arról, mikor fejeződik be a munka a jelenlegi ütem fenntartásával. Más szavakkal, a Burndown Chart a feladatok tényleges ütemét mutatja, és az ideális vonal azt mutatja, hogy milyen ütemben kellene a Csapatnak dolgoznia a feladatok befejezéséhez.

A Burndown Chart lehetővé teszi a Fejlesztő Csapat Sebességének meghatározását is hosszú távon. Ezt külön cikknek szentelünk. Itt csak annyit említünk meg, hogy ez az egy Sprint alatt elvégzett munka mennyiségével meghatározott érték.

Azáltal, hogy a Burndown Chart illusztrálja az ideális égési vonal és a feladatok számának valós csökkenésének összehasonlítását, lehetővé teszi a munka ütemének becslését. És így előre jelezheti a projekt késedelmének kockázatát.

A mérési egység kiválasztása

A csapat sebességét általában történetpontokban mérik. Ez meghatározza a megvalósított felhasználói történetek számát. Ezek nagyon eltérő mennyiségű munkát igényelhetnek.

Ezért sok Scrum Csapat időalapú mérést használ. A skálától függően ezek napok vagy munkaórák. Minden Fejlesztő megbecsüli, majd rögzíti a feladataira fordított idő mennyiségét.

Másik lehetőség, hogy feladatokat fogadunk el egységként. Ezek kissé nagyobb egységek, amelyekhez történetpontokban, vagy napokban vagy munkaórákban kifejezett értéket rendelnek. Ez egy olyan egység, amely lehetővé teszi az ügyfél számára, hogy világosabban bemutassa a terméken végzett munka előrehaladását.

Függetlenül a mérési egységtől, érdemes emlékezni a Fejlesztő Csapat sebességének kiszámításának elvére. Egy adott napon vagy Sprintben csak a ténylegesen befejezett feladatok számítanak. Ez azt jelenti, hogy a megkezdett feladatokat a következő napra vagy Sprintre számolják, még akkor is, ha csak a végső tesztelés hiányzik.

Összefoglalás

A csapat figyelemmel kísérő eszközeivel a Burndown Chart készítése könnyű feladattá válik. A legfontosabb kérdés a koherencia, a világosság és az elérhetőség biztosítása minden Scrum Csapat tag számára.

Ha tetszik a tartalmunk, csatlakozz a szorgos méheink közösségéhez a Facebookon, Twitteren, LinkedInen, Instagramon, YouTube-on, Pinteresten.

Caroline Becker

Projektmenedzserként Caroline szakértő az új módszerek megtalálásában, amelyek a legjobb munkafolyamatok megtervezésére és a folyamatok optimalizálására szolgálnak. Szervezési készségei és a nyomás alatt végzett munka iránti képessége teszik őt a legalkalmasabb személyré, aki bonyolult projekteket valóra tud váltani.

View all posts →