Burndown chart, czyli wykres spalania, pokazuje, ile pracy pozostało zespołowi do wykonania w stosunku do upływającego czasu. W Scrumie pomaga śledzić postęp sprintu, zauważać ryzyko opóźnienia i rozmawiać o zmianach w zakresie prac. Nie jest obowiązkowym artefaktem Scruma, lecz użytecznym narzędziem komunikacji i samoorganizacji zespołu.
Jak zbudowany jest burndown chart?
Wykres ma dwie podstawowe osie. Oś X przedstawia czas, najczęściej kolejne dni Sprintu. Oś Y pokazuje ilość pracy pozostałej do wykonania. Może być wyrażona w godzinach, Story Points albo liczbie zadań, ale w obrębie jednego wykresu trzeba zachować jedną, spójną jednostkę.
Na wykresie znajdują się zwykle dwie linie. Linia idealnego trendu prowadzi od całego zakresu prac na początku sprintu do zera w jego ostatnim dniu. Jest punktem odniesienia, a nie prognozą uwzględniającą wszystkie rzeczywiste wahania tempa pracy. Linia rzeczywistego postępu pokazuje, ile pracy faktycznie pozostawało zespołowi w poszczególnych dniach.
Przykładowo, jeśli sprint zaczyna się od 40 Story Points, punkt początkowy znajduje się na poziomie 40. W miarę kończenia zadań linia rzeczywista powinna zbliżać się do zera. Nie musi jednak opadać równomiernie. Zadania różnią się złożonością, a część problemów ujawnia się dopiero podczas realizacji.
Jak stworzyć burndown chart?
Prosty wykres można przygotować w narzędziu do zarządzania projektami, arkuszu kalkulacyjnym albo na tablicy. Potrzebujesz zakresu sprintu, czasu jego trwania i aktualnych danych o pozostałej pracy. Proces wygląda następująco:
- Określ zakres prac – zbierz elementy z Backlogu sprintu, które zespół zamierza ukończyć.
- Wybierz jednostkę – zdecyduj, czy pozostałą pracę mierzysz w godzinach, Story Points czy liczbie zadań.
- Ustal ramy czasu – zaznacz na osi X dni sprintu, a na osi Y początkową ilość pracy.
- Narysuj linię idealną – połącz wartość początkową z zerem przypadającym na koniec sprintu.
- Aktualizuj dane codziennie – po wykonaniu pracy zapisz, ile wysiłku lub zadań nadal pozostało.
Aktualizowana jest ilość pracy pozostałej, a nie sama liczba wykonanych czynności. Jeśli nowe zadanie pojawia się w trakcie sprintu, powinno zostać uwzględnione w danych, gdy rzeczywiście należy do pracy potrzebnej do osiągnięcia celu sprintu. Ukrywanie takiej zmiany zniekształca obraz sytuacji.
Jak czytać wykres i co oznaczają odchylenia?
Najważniejsze jest porównanie linii rzeczywistej z idealnym trendem. Sam kształt wykresu nie wyjaśnia jeszcze przyczyny problemu. Pokazuje sygnał, który zespół powinien omówić podczas codziennej pracy, a nie ocenę konkretnych osób.
Najczęstsze sytuacje na wykresie można odczytać w następujący sposób:
- Linia pokrywa się z idealną – tempo pracy jest zbliżone do założonego, choć nadal trzeba sprawdzać jakość i kompletność danych.
- Linia znajduje się powyżej idealnej – pozostało więcej pracy, niż wynikałoby z planu. Przyczyną może być wolniejsze tempo, zbyt ostrożne szacunki albo rozszerzenie zakresu.
- Linia znajduje się poniżej idealnej – zespół ma mniej pracy do wykonania, niż zakładano na tym etapie. Może to oznaczać wyprzedzenie planu, ale także zbyt optymistyczne oszacowanie lub zamknięcie zadań o małej wartości.
- Linia pozostaje płaska – przez pewien czas nie zmniejsza się ilość pracy pozostałej. Zespół może być zablokowany, pracować nad zadaniami, których jeszcze nie ukończył, albo nie aktualizować wykresu.
- Linia idzie w górę – ilość pracy pozostałej wzrosła. Nie musi to oznaczać regresu, ponieważ zespół mógł odkryć dodatkowe czynności, defekty albo wymagania potrzebne do ukończenia zadania.
Wzrost linii jest szczególnie ważnym sygnałem diagnostycznym. Podczas implementacji funkcji zespół może lepiej poznać jej złożoność i dopisać brakujące zadania. Podobnie działa wykrycie błędów, które trzeba naprawić, albo doprecyzowanie rozwiązania wspólnie z Product Ownerem. Taka zmiana zwiększa zakres widocznej pracy, ale może jednocześnie poprawić realną wartość produktu.
Jeśli wykres stale znajduje się powyżej linii idealnej, zespół powinien sprawdzić, czy problem dotyczy tempa, zakresu czy szacowania. Warto omówić blokery, zależności i możliwość ograniczenia mniej istotnych prac z Product Ownerem. Gdy linia pozostaje płaska, trzeba ustalić, czy zadania są faktycznie wykonywane, czy tylko przesuwają się między statusami.
Linia poniżej trendu idealnego nie zawsze oznacza, że można bez ryzyka dodać kolejne zadania. Najpierw należy sprawdzić, czy prace spełniają kryteria ukończenia i czy nie pominięto testów, integracji lub dokumentacji. Wykres pokazuje ilość pozostałej pracy, ale nie zastępuje rozmowy o jakości.
Burndown czy Burnup – co wybrać?
Oba wykresy pokazują postęp, lecz koncentrują się na innej stronie pracy. Burndown przedstawia to, co jeszcze zostało, a Burnup to, co już ukończono. Burnup może też wyraźniej pokazywać zmianę całkowitego zakresu, ponieważ osobna linia może przedstawiać jego rozmiar.
| Cecha | Burndown chart | Burnup chart |
|---|---|---|
| Główny cel | Pokazuje pozostałą pracę | Pokazuje ukończoną pracę |
| Oś Y | Praca, która nadal czeka na wykonanie | Praca ukończona, zwykle w Story Points lub elementach |
| Kierunek linii | Zwykle maleje w stronę zera | Zwykle rośnie wraz z realizacją zakresu |
| Najlepsze zastosowanie | Ocena, czy pozostały zakres zmieści się w czasie | Pokazanie postępu i zmian całkowitego zakresu |
Na co uważać podczas pracy z wykresem?
Burndown chart jest tak wiarygodny, jak dane, na których go oparto. Sama automatyzacja w Jira, Azure DevOps lub innym narzędziu nie naprawi błędnych estymacji ani nieaktualnych statusów. W praktyce najlepiej traktować wykres jako punkt wyjścia do rozmowy zespołu.
Najczęstsze problemy i dobre praktyki to:
- Regularność – aktualizuj dane codziennie, najlepiej w rytmie pracy zespołu, aby wykres nie opierał się na kilkudniowym opóźnieniu.
- Jakość danych – ustal, kiedy zadanie jest uznawane za ukończone i konsekwentnie stosuj tę zasadę.
- Spójna jednostka – nie mieszaj godzin, Story Points i liczby zadań na jednej osi, ponieważ każda z tych miar opisuje coś innego.
- Rozmowa o przyczynach – odchylenie od linii idealnej jest sygnałem do analizy, a nie gotowym wyjaśnieniem.
- Brak mikrozarządzania – nie używaj wykresu jako narzędzia kontroli pojedynczych deweloperów. Służy do oceny sytuacji zespołu i wspólnej adaptacji planu.
- Widoczny zakres – zapisuj zmiany w Backlogu sprintu, aby było jasne, czy wzrost pracy wynika z trudności, defektów czy nowych ustaleń.
Wykres może wspierać rozmowę z Product Ownerem o priorytetach i zakresie, ale nie powinien służyć do uzasadniania z góry ustalonej decyzji. Gdy stale pokazuje opóźnienia, a zespół nie potrafi wskazać przyczyny, potrzebna jest szersza analiza sposobu planowania, zależności i definicji ukończenia.
Burndown chart nie jest celem sprintu. Jego wartość polega na tym, że szybko pokazuje pozostałą pracę i pomaga zespołowi reagować, zanim problem wpłynie na wynik sprintu. Używany jako wspólne narzędzie komunikacji zwiększa przejrzystość, zamiast zamieniać się w raport kontroli.
