Burndown chart
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).
TL;DR
Wykres spalania to narzędzie, które pozwala śledzić postęp prac w trakcie sprintu. Jest prosty w wykonaniu i czytelny wizualnie. Analiza wykresu pozwala ocenić, czy prace idą zgodnie z planem. Może być używany w metodykach zwinnych i kaskadowych. Wartością dodaną jest możliwość połączenia analizy z innymi narzędziami, np. Metodą Wartości Wypracowanej. Jednak wykres spalania ma swoje wady - może prowadzić do niepoprawnej interpretacji wyników, nie uwzględnia zależności między zadaniami i nie wskazuje przyczyn opóźnień.
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).
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ń
| Burndown chart — artykuły polecane |
| Estymacja czasu trwania zadań — Metoda łańcucha krytycznego — Earned Value — Backlog sprintu — Bilansowanie zasobów — Rezerwy w projekcie — Optymalizacja wykorzystania zasobów (poziomowanie) — Szacowanie czasu trwania zadań — Kontrola w projekcie |
Przypisy
Bibliografia
- Chrapko M. (2015), Scrum: o zwinnym zarządzaniu projektami, Wydawnictwo Helion, Gliwice
- Kaczor K. (2018), Scrum i nie tylko. Teoria i praktyka w metodach Agile, Wydawnictwo naukowe PWN, Warszawa
- Sachdeva S. (2016), Scrum Methodology, International Journal Of Engineering And Computer Science, nr 5
- Sutherland J. (2006), A Brief Introduction to Scrum, Scrum Alliance
- Wyrozębski P. (2011), Metodyki zarządzania projektami, Bizarre, Warszawa
Autor: Polina Ponochevna
