Burndown chart

Burndown chart
Polecane artykuły


Wykres spalania (ang. Burndown chart) jest wizualizacją pozostałych do wykonania prac w trakcie trwania sprintu. Ta nazwa bardzo dobrze opisuje charakter danego wskaźnika - pozwala śledzić, dosłownie, jak szybko robota "pali nam się w rękach”[1].

Celem stosowania wykresu spalania jest dostarczenie zespołowi projektowemu (scrum-owemu) aktualnych informacji na temat ilości pracy, pozostałej do końca sprintu, dzięki czemu można ocenić poziom realizacji harmonogramu. Mimo to, na podstawie analizy wykresu spalania można wyciągać cenne wnioski dotyczące pracy zespołowej. Wykres spalania jest potężnym narzędziem w rękach Scrum Master’a. Pozwala on na odpowiednio szybką adaptację Development Team’u do zmian występujących w projekcie, zapobiega konfliktom z Product Owner’em na koniec sprintu oraz motywuje Development Team do coraz lepszej samoorganizacji. Dobry Scrum Master powinien dbać o codzienne aktualizacje wykresu spalania oraz o jego znajomość i zrozumienie w całym Scrum Team’ie. Warto dbać również o jakość wykresu, ponieważ w pewnych sytuacjach może się przydać w negocjacjach w Właścicielem Produktu (Product Owner).

Tworzenie Wykresu Spalania

Wykresy spalania są niezwykle prostym narzędziem jak w wykonaniu, tak i w monitorowaniu. Do stworzenia wykresu potrzebujemy dwóch informacji: długości trwania projektu lub sprintu oraz ilości pracy do wykonania. Mając te dane można wykreślić układ współrzędnych, który posłuży za kanwę Wykresu Spalania.

Dla wykonania wykresu pierwszym etapem trzeba przygotować tabelę z danymi zgodnie z harmonogramem. Przy tym można użyć liczbę zadań albo też liczbę roboczogodzin. Wykorzystując tabelę można sporządzić wykres dla danych planowanych oraz Linie trendu (Droga do sukcesu), która pokazuje w jakim tempie powinny postępować prace, żeby cel sprintu został osiągnięty i wszystkie zaplanowane zadania zostały wykonane na czas. Na osi poziomej umieszczamy ilość zaplanowanych dni (sprintów), oś pionowa pokazuje liczbę zadań które musimy wykonać do końca sprintu (projektu). Tak samo przygotowujemy tabelę zgodnie z rzeczywistym postępem prac. W tej tabeli wpisujemy faktyczną liczbę wykonanych zadań, porównując z liczbą zadań zaplanowanych (Tab. 1).

Dzień Planowana liczba zadań Planowana liczba zadań do końca Rzeczywista liczba zadań Rzeczywista liczba zadań do końca
1 2 96 4 96
2 3 94 3 92
3 0 91 4 89
4 2 91 5 85
5 1 89 1 80
6 17 88 12 79
7 1 71 2 67
8 1 70 4 65
9 1 69 5 61
10 12 68 5 56
11 15 56 0 51
12 11 41 5 51
13 9 30 10 46
14 8 21 8 36
15 1 13 2 28
16 1 12 2 26
17 8 11
18 1 3
19 1 2
20 1 1
SUMA 96 0 96 24

Przykład: Pierwszego dnia zaplanowaliśmy wykonać 4 zadania, natomiast udało się nam wykonać 6, z czego jedno zadanie było nieuwzględnione w harmonogramie, w takim razie wpisujemy rzeczywistą liczbę wykonanych zadań – 5. Nie powinniśmy uwzględniać zadań nieobjętych harmonogramem, które pojawiają się w trakcie realizacji projektu, jeżeli nie robimy stałej aktualizacji planu. Inaczej każde nadprogramowe zadanie zafałszuje rzeczywisty wygląd wykresu. Odnosimy się tylko do zadań, które są zaplanowane. Sporządzamy krzywą na podstawie nowej tabeli na tym samym wykresie. Końcowy wykres wygląda następująco (Rys. 1).

Rys. 1 Przykładowy Wykres Spalania

W idealnej sytuacji linia wykresu skierowana jest do dołu. Jednakże w praktyce, mogą zdarzyć się przypadki, gdy pomimo wykonanej pracy ilość pracy pozostałej jeszcze wzrośnie. Może wystąpić to m.in. w przypadku gdy:

  • w trakcie realizacji funkcjonalności zespół zdobywa większą wiedzę o faktycznej złożoności zadania i może podjąć decyzję o dodaniu niezbędnych czynności do wykazu prac sprintu;
  • rozpoznane wady i defekty mogą wymagać zajęcia się nimi w postaci osobnych, dodatkowych zadań;
  • zaistnieje możliwość doprecyzowania celów i wprowadzenia we współpracy z właścicielem produktu drobnych zmian, zwiększających wartość dla klienta, ale nie powodujących wydłużenia czasu sprintu[2].

Analiza Wykresu Spalania

Analiza wykresu spalania jest bardzo prosta – jeżeli linia dla zadań zaplanowanych i rzeczywiście wykonanych się pokrywa, to znaczy że poruszamy się zgodnie z planem. W sytuacji, gdy linia faktycznie wykonanych zadań znajduje się poniżej linii planowanej, można powiedzieć o wyprzedzaniu harmonogramu. W przypadku, gdy linia rzeczywista znajduje się powyżej linii zaplanowanej, to oznacza, że projekt jest zagrożony, ponieważ postęp prac w projekcie nie jest wystarczający. To może wskazywać na opóźnienie grożące przekroczeniem terminu realizacji etapu albo projektu lub sygnalizować jedynie o chwilowym opóźnieniu związanym z nierównomiernym rozłożeniem prac. W idealnej sytuacji zaplanowana liczba zadań powinna tworzyć linię prostą, równomiernie spadającą wraz z czasem. W rzeczywistości trzeba się dążyć jedynie do równomiernego rozłożenia prac. W przypadku, gdy jesteśmy poniżej harmonogramu warto zaangażować dodatkowe zasoby, uwzględniając czas i koszty potrzebne na wdrożenie nowych osób w projekt. Innym wyjściem w takiej sytuacji jest skrócenie zakresu projektu (część projektu nie zostanie wykonana, ale projekt, jako całość, ma szansę skończyć się w terminie) lub przedłużenie terminu realizacji projektu, co niestety może powodować utratę reputacji.

Zalety i wady wykresu spalania

Zalety:

  • Prostota wykonania
  • Czytelna wizualizacja postępu prac w projekcie
  • Możliwość monitorowania i kontroli postępu prac
  • Szybka analiza stanu projektu w przypadku zmian
  • Możliwość połączenia analizy z innymi narzędziami np. Metodą Wartości Wypracowanej
  • Nic nie stoi na przeszkodzie, aby w podobny sposób analizować np. stopień realizacji budżetu
  • Możliwość zastosowania w metodykach zwinnych oraz kaskadowych

Wady:

  • Możliwość niepoprawnej interpretacji wyników (wykonanie dużej ilości zadań nie musi oznaczać postępu projektu)
  • Nie uwzględnia zależności między zadaniami
  • Nieskuteczny w razie złego oszacowania pracochłonności zadań
  • Nie wskazuje przyczyn zaistniałych opóźnień

Bibliografia

  • Chrapko M., (2013), SCRUM. O zwinnym zarządzaniu projektami, Helion
  • Kaczor K., (2014), SCRUM i nie tylko. Teoria i praktyka w metodach Agile, PWN
  • Sutherland J., (2006), A Brief Introduction to Scrum, Scrum Alliance
  • Sachdeva S., (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5
  • Wyrozębski P., (2011), Metodyka SCRUM w Metodyki zarządzania projektami, Bizarre, Warszawa
  • Pfahl D., (2014), Methods, University of Tatru, nr 11

Przypisy

  1. M. Chrapko, (2013), SCRUM. O zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice, s. 233
  2. P. Wyrozębski, (2011), Metodyka SCRUM [w] Metodyki zarządzania projektami, Bizarre, Warszawa, s. 262-263.

Autor: Polina Ponochevna