Wykres spalania - jak go tworzyć i interpretować?

Wykres spalania jest stosunkowo łatwy do stworzenia. Istnieje wiele narzędzi pozwalających na jego generowanie na podstawie pracy logowanej przez członków Zepołu Developerskiego. Pomimo prostoty, jego interpretacja może być źródłem cennych informacji dla całego Scrum Team.

Wykres spalania – omówione zagadnienia:

Jak tworzyć wykres spalania?
Kto jest odpowiedzialny za wykres spalania?
Jak interpretować wykres spalania?
Podsumowanie

Jak tworzyć wykres spalania?

Zespół Developerski powinien monitorować swoją codzienną pracę. Jest to podstawą nie tylko oceny jego efektywności, lecz także jej poprawy. Zaś jednym z najprostszych i sprawdzonych narzędzi służących do tego celu jest wykres spalania.

Można stworzyć go ręcznie, rysując na kartce papieru układ współrzędnych. Na osi Y trzeba nanieść ilość pracy wyrażoną w wybranej jednostce, na przykład story points. Na osi X wyrysować skalę wyznaczającą kolejne dni Sprintu. Wyrysować linię idealnego spalania, a potem dla każdego dnia oznaczać ilość realnie zrealizowanych zadań. Choć to rozwiązanie urocze i angażujące Zespół, jest niezbyt praktyczne. Niekoniecznie sprawdzi się też w przypadku Zespołu pracującego zdalnie.

Dlatego znacznie powszechniejsze są cyfrowe sposoby tworzenia wykresu spalania. Wiele narzędzi służących do logowania pracy nad zadaniami rozdzielonymi pomiędzy członków Zespołu, jest wyposażonych w opcję automatycznego tworzenia wykresu spalania. Wtedy wystarczy, że Developer oznaczy rozpoczęcie i zakończenie pracy nad daną funkcjonalnością produktu, a jego wkład znajdzie odzwierciedlenie na wykresie spalania.

Dzięki użyciu narzędzi możliwe jest też dowolne skalowanie wykresu. Daje to wgląd w spalanie nie tylko na poziomie danego Sprintu, lecz również w skali kwartału czy całego projektu.

Ważnym czynnikiem, jaki trzeba wziąć pod uwagę przy wyborze narzędzia służącego do tworzenia wykresu spalania jest jego dostępność dla wszystkich członków Scrum Team. Widoczność wykresu spalania dla całego Zespołu Developerskiego jest kluczowym czynnikiem motywacyjnym. Równie ważne jest codzienne spojrzenie na linię ukazującą pracę pozostałą do wykonania. Rozmowa na temat spalania podczas Daily Scrum, któremu poświęciliśmy osobny artykuł, skłania Developerów do zastanowienia nad sposobami pracy i bieżącym stanem Produktu.

Kto jest odpowiedzialny za wykres spalania?

Kwestia własności wykresu spalania budzi nieco kontrowersji. Z jednej strony powinien on należeć do Scrum Mastera, ponieważ jest narzędziem pozwalającym upewnić się, że Zespół pracuje wydajnie i zgodnie z planem. Z drugiej strony, powinien należeć do Product Ownera, ponieważ odzwierciedla postęp na drodze do Celu Produktu, który może zostać przekazany Klientowi. Z trzeciej natomiast – jest wewnętrznym narzędziem Zespołu Developerskiego.

Wykres spalania jest bardzo ważną metryką pozwalającą ocenić efektywność Zespołu Developerskiego i korzystają z niego wszyscy członkowie Scrum Team. Dlatego tak istotna jest jego przejrzystość i dostępność. Jednak samo jego prowadzenie ma w założeniu służyć przede wszystkim Zespołowi. Ma wzmacniać jego samoorganizację, poprawiać motywację, oraz dawać realny obraz stanu prac nad powierzonymi mu zadaniami. Dlatego w teorii każdy z członków Zespołu Developerskiego może aktualizować wykres spalania.

W praktyce jednak zadanie aktualizowania wykresu spalania przypada zwykle Scrum Masterowi. Dzieje się tak szczególnie na początku jego pracy z nowym Zespołem Developerskim, kiedy Prędkość Zespołu jest jeszcze zmienna i trudna do oszacowania. Niemniej jednak zaleca się przekazanie tego zadania jednemu z Developerów. Wykres spalania ma być bowiem szczerą i wewnętrzną miarą postępów w pracy tak, jak oceniają ją sami Developerzy.

Jak interpretować wykres spalania?

Wygląd wykresu spalania opisaliśmy szczegółowo w poprzednim artykule. Tutaj przypomnimy tylko, że na osi X przedstawiony jest czas pozostały na wykonanie pracy. Natomiast na osi Y widoczna jest ilość pracy pozostałej do wykonania.

Spalanie realne i idealne

Dla interpretacji wykresu spalania bardzo ważnym czynnikiem jest nie tylko regularne nanoszenie realnego „spalania”, czyli realizacji zadań przez Zespół Developerski. Równie istotne dla obrazu sytuacji jest jego porównanie z idealnym spadkiem linii spalania (guideline).

Dzięki porównaniu idealnej linii spalania z realnym zmniejszaniem ilości pracy oznaczanym na wykresie spalania, można ocenić dwa bardzo istotne parametry. Po pierwsze sprawdzić, czy jeśli praca będzie przebiegać w dotychczasowym tempie, Zespół Developerski zrealizuje na czas Cel Sprintu lub Cel Produktu. Po drugie, zorientować się, kiedy prace zostaną ukończone przy utrzymaniu obecnego tempa. Innymi słowy, wykres spalania obrazuje rzeczywiste tempo realizacji zadań, zaś linia idealna pokazuje w jakim tempie Zespół powinien pracować aby ukończyć założone zadania.

Wykres spalania pozwala także w dłuższej perspektywie określić wartość nazywaną Prędkością Zespołu Developerskiego. Poświęcimy jej osobny artykuł. Tutaj wspomnimy tylko, że jest to wartość wyznaczana przez ilość pracy wykonanej w czasie jednego Sprintu.

Dzięki temu, że wykres spalania obrazuje porównanie idealnej linii spalania z realnym zmniejszaniem ilości zadań, pozwala szacować tempo pracy. A tym samym przewidywać ryzyko opóźnień w realizacji projektu.

Wybór jednostki pomiaru

Prędkość Zespołu zwykle mierzona jest w jednostkach nazywanych story points. Określa ona ilość zrealizowanych user stories. Te zaś mogą wymagać bardzo różnego nakładu pracy.

Dlatego wiele Scrum Teams stosuje miarę czasową. W zależności od skali są to dniówki lub osobogodziny. Każdy z Developerów szacuje, a następnie loguje ilość czasu poświęconego na wykonanie swoich zadań.

Kolejną opcją jest wykorzystanie jako jednostki zadań (tasks). Są to nieco większe całości, którym z kolei może zostać przypisana wartość wyrażona w story points, albo w dniówkach czy osobogodzinach. Jest to jednostka pozwalająca przedstawić Klientowi postępy w pracy nad Produktem w bardziej czytelny sposób.

Niezależnie od zastosowanej jednostki pomiaru, warto pamiętać o zasadzie obliczania prędkości Zespołu Developerskiego. W danym dniu lub Sprincie ,strong>liczą się tylko zadania, które zostały realnie ukończone. Oznacza to, że rozpoczęte zostaną zaliczone na poczet następnego dnia bądź Sprintu nawet jeśli zabrakło tylko finalnych testów.

Podsumowanie

How to create and interpret a burndown chart?

Interpretacja wykresu spalania, niezależnie od wybranej skali czy jednostki pomiaru, pozwala określić:

tempo wykonywania zadań
ryzyko opóźnień w realizacji projektu
szacowaną Prędkość Zespołu Developerskiego

Dzięki dostępnym narzędziom służącym do monitorowania pracy zespołowej samo tworzenie wykresu spalania nie jest skomplikowane. Najważniejsze jest zapewnienie jego czytelności. A także dostępności dla wszystkich członków Scrum Team.

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty