Blog

Wykres spalania (ang. burndown chart) to jedno z najczęściej używanych narzędzi do monitorowania postępu prac np. w trakcie Sprintu w Scrumie. Sposób jego sporządzania jest banalny: każdego dnia na wykresie odkładana jest liczba rzeczy, jakie pozostają do zrobienia. Taki wykres wizualizuje tempo ubywania tych rzeczy (ich spalania), co wyjaśnia, skąd wzięła się jego nazwa.

Samo monitorowanie postępu prac polega na analizie przebiegu wykresu w ciągu kolejnych dni:

• jeśli wykres zaczyna przebiegać poziomo, postępu brak;
• jeśli z jakiegoś powodu wykres wznosi się w górę, zamiast opadać, jest to sygnał, że przybyło pracy do wykonania, która początkowo nie była planowana;
• jeśli wykres opada, tempo tego spadku pozwala ocenić, jak dużo pracy zostanie wykonane do określonej daty.

Bardzo często na wykres nakładana jest jakaś linia lub krzywa, która obrazuje trend i ułatwia ekstrapolowanie kolejnych wartości, ale nigdy nie zapewnia, że będą one takie czy inne, bo to zawsze jedynie zgadywanie, jak przebiegać będą prace w przyszłości.

Jeśli praca odbywa się w iteracjach, na których początku odbywa się planowanie zakresu prac do wykonania, wtedy często burndown chart uzupełniany jest linią tzw. spalania idealnego – prostą linią, która zaczyna się pierwszego dnia iteracji i pokazuje, ile rzeczy jest do zrobienia, a kończy dnia ostatniego na poziomie zero. Inaczej mówiąc, jest to wizualizacja tego, jak wyglądałoby spalanie, gdyby każdego dnia udało się wykonać dokładnie tyle samo pracy. Mogłoby się tak stać, jeśli spełnione byłyby jednocześnie następujące warunki:

• każda praca może być podzielona na kwanty na tyle małe, że da się je wykonać w ciągu jednego dnia,
• realizację tych kwantów da się ułożyć tak, że tempo pracy każdego dnia będzie takie samo,
• wykonanie pracy zawsze przebiega zgodnie z planem.

W oczywisty sposób te warunki realnie nie mogą być spełnione, dlatego właśnie tę linię nazywa się wykresem spalania idealnego. Ma ona stanowić punkt odniesienia dla wykresu spalania rzeczywistego. Gdy przebiega on ponad linią spalania idealnego, niektórzy uznają, że praca idzie wolniej, niż powinna. Gdy pod nią – że lepiej niż się można było spodziewać. Czy takie oceny mają jakikolwiek sens? Nie, prawie zawsze są go pozbawione.

Co się spala na wykresie?

Technika nie określa, z czego składać ma się zbiór rzeczy do zrealizowania, czyli co spalać się powinno w miarę upływu czasu. Najczęściej można spotkać się z trzema podejściami, które warto zaprezentować na przykładzie wykresu spalania jakiegoś Zespołu Scrum pracującego w dwutygodniowych Sprintach.

Opcja 1: liczba niezrealizowanych elementów Backlogu Produktu

Skoro zadaniem Zespołu jest zrealizowanie w Sprincie jakiegoś zbioru elementów Backlogu Produktu (ang. Product Backlog items, w skrócie PBI) i osiągnięcie w ten sposób ustalonego Celu Sprintu, najsensowniejszym rozwiązaniem wydaje się każdego dnia sprawdzać, ile tych PBI wciąż pozostało do zrealizowania.

Oto przykład tego, jak mógłby wyglądać wykres spalania na początku siódmego dnia roboczego Sprintu:

Czy Zespołowi idzie nieźle? Chyba nie, bo do końca iteracji pozostało niewiele czasu, a realnie ukończona została praca nad zaledwie dwoma elementami Backlogu Produktu.

A gdyby przebieg prac w tym Sprincie wyglądał na początku siódmego dnia w sposób przedstawiony poniżej?

Spalanie idzie rewelacyjnie, a do zrobienia pozostały jeszcze tylko dwa PBI. Można więc pokusić się o ocenę, że sytuacja jest korzystna.

Niestety, taki sposób oceniania postępu prac byłby bardzo nierozsądny. Czemu?

Pierwszy z przykładowych wykresów pokazuje, że pozostało wciąż siedem elementów Backlogu Produktu do zrealizowania, ale przecież mogą to być jakieś drobiazgi, których wykonanie potrwa krócej niż pół dnia. Inaczej mówiąc, być może dwa już ukończone PBI wiązały się z realizacją np. 95% wszystkich prac w tym Sprincie. Nie dość więc, że sytuacja wcale nie jest zła, to jeszcze pozostanie trochę wolnego czasu w iteracji, zanim ona się zakończy.

Równie zwodniczy może być pozytywny przekaz drugiego przykładowego wykresu. Być może te dwa PBI, które wciąż muszą być zrealizowane, wymagają 90% wysiłku Developerów w Sprincie? W takim przypadku sytuacja jest – delikatnie mówiąc – zła.

Wyłania się więc pierwszy poważny problem z użyciem burndown chartów do monitorowania postępu prac: bez uzupełnienia wizualizacji dodatkową informacją o faktycznej ilości pracy, przestaje ona być użyteczna, a może wręcz wprowadzać w błąd.

Dlatego wiele Zespołów decyduje się inaczej sporządzać swe burndown charty, jeśli już się nimi posługuje.

Opcja 2: suma oszacowań niezrealizowanych PBI

Skoro wielkość realizowanych elementów Backlogu Produktu ma istotne znaczenie, sensowniejszym będzie odłożenie na wykresie nie tyle liczby PBI, ile sumy ich oszacowań, wyrażonej np. w story pointach, jeśli akurat nimi posługuje się Zespół. Wykres spalania zacznie wtedy wyglądać np. tak:

Nieco lepiej teraz widać, ile pracy wciąż pozostało do wykonania. Z dużo większą pewnością, niż wcześniej, można stwierdzić, że przykładowy Sprint nie przebiega zbyt dobrze. Ba, ponad połowa rzeczy wciąż wymaga zrobienia, więc jest naprawdę źle! No, chyba że jednak nie…

Wykres uwzględnia teraz wielkość elementów Backlogu Produktu, ale nie pokazuje postępu prac nad nimi. Inaczej mówiąc, opada w dół dopiero po skończeniu prac, a nie w trakcie, niezależnie od tego, jak one są zaawansowane. Być może Zespół jest o krok od ukończenia wszystkiego, co realizuje w Sprincie.

Nie udało się więc wyeliminować wzmiankowanej wcześniej słabości burndown chartu, choć skala przekłamania jest teraz zapewne mniejsza.

Wniosek: wykres musi być nieco bardziej detaliczny, czyli nie może skupiać się wyłącznie na liczbie PBI oczekujących na realizację, ani nawet na ich oszacowaniach. Można tak zrobić? Oczywiście.

Opcja 3: oszacowanie ilości pracy pozostałej do wykonania

Realizowane elementy Backlogu Produktu są różnej wielkości, która zmniejsza się w miarę postępu prac nad nimi. Jeśli przykładowy PBI został wyszacowany na 8 story pointów, można powiedzieć, że po wykonaniu 50% niezbędnych działań, pozostanie tych punktów tylko 4. W ten sposób, szacując każdego dnia, ile pracy pozostało jeszcze do zrobienia w każdym z PBI, można sporządzić wykres spalania pozbawiony wspomnianej wcześniej wady:

O ile nikt nie spodziewa się, że praca będzie przebiegać dokładnie wzdłuż linii spalania idealnego, to można powiedzieć, że przykładowy Sprint idzie całkiem, prawda? Cóż, nie da się tego stwierdzić z całą pewnością.

Wada, jaką miały poprzednio opisane sposoby sporządzania wykresu spalania, zastąpiona została przez dwie inne, równie dotkliwe.

Pierwsza jest dość oczywista i wynika wprost z tego, co teraz przedstawia wykres. Nie widać na nim, czy jakikolwiek PBI został już ukończony. Inaczej mówiąc, być może Zespołowi uda się spalić niemal do zera wszystkie story pointy w poszczególnych elementach Backlogu Produktu, ale żadnego z nich ostatecznie przed końcem Sprintu nie zrealizuje. Wykres będzie wyglądał pięknie, choć sytuacja będzie dramatycznie zła.

Druga wada jest mniej oczywista, a wynika ze sposobu sporządzania tego wykresu. Developerzy zmuszeni są do codziennego szacowania ilości pracy, jaka pozostała do wykonania. Albo zabierze to sporo czasu, albo wiarygodność wycen, a tym samym i wykresu, będzie bardzo niska.

Złośliwie można zatem stwierdzić, że w ramach kolejnych „usprawnień” burndown chartu można przejść od wizualizacji, która nie pokazuje rzeczywistego postępu prac, do takiej, która nie pozwala zobaczyć, czy cokolwiek udało się już skończyć.

Opcja 4: zadania do wykonania i ich czasochłonność

Jak pozbyć się obu wspomnianych wad i czy jest to w ogóle możliwe? Na pewno da się uniknąć konieczności codziennego szacowania każdego z PBI, które są aktualnie realizowane. Zamiast tego Developerzy mogą już na początku iteracji (czyli w trakcie Planowania Sprintu) wypisać czynności (zadania), jakie trzeba będzie wykonać w ramach realizacji każdego z elementów Backlogu Produktu. Liczba takich zadań będzie różna, zależna od wielkości PBI, a ich suma może być użyta do sporządzania wykresu spalania.

I w ten sposób, zamiast szacować postęp prac każdego dnia, wystarczy policzyć, ile zadań wciąż pozostało do wykonania:

Ten sposób budowania burndown chartów będzie też typowy w Zespołach, które nie chcą posługiwać się po prostu liczbą niezrealizowanych PBI (czyli wersją wykresu opisaną na samym początku), a nie stosują numerycznych oszacowań tylko np. rozmiary koszulek. Zamiast kombinować, jak przedstawić na wykresie sumę XXL + XS + M + S, mogą zdefiniować zadania niezbędne do zrealizowania wycenianych w ten sposób PBI i posłużyć się informacją o liczbie takich zadań.

Niektóre Zespoły idą zresztą jeszcze dalej i poza zdefiniowaniem zadań, dodatkowo szacują czas ich realizacji w dniach, połówkach dni czy np. godzinach, żeby od razu sprawdzić, czy aby nie ma ich zbyt wiele w stosunku do czasu dostępnego w Sprincie. A potem na wykresie spalania przedstawiają już nie liczbę niezrealizowanych zadań, ale sumę oszacowań ich czasochłonności.

Przykład takiego wykresu:

Panuje przekonanie, że to jest najlepsza (w domyśle: najbardziej precyzyjna) forma wykresu spalania. Cóż, nie jest to prawda.

Po pierwsze, odrywa się on całkowicie od elementów Backlogu Produktu, więc w inny sposób trzeba analizować ich faktyczny stan. Inaczej mówiąc, taki wykres w ogóle nie ma szans pokazać, czy cokolwiek udało się skończyć.

Po drugie, jest to przede wszystkim mechanizm monitorowania tego, czy Developerzy trzymają się planów i właściwie niczego więcej. To może wpychać Developerów w przekonanie, że skoro robota idzie tak, jak zaplanowali, musi być dobrze. Rzadko natomiast pojawi się refleksja, że przecież plany mogą być nietrafione…

Po trzecie, precyzja jest absolutnie pozorna, bo opiera się na oszacowaniach zadań, które przecież zawsze obarczone są błędem. Ba, w istocie jest ona niższa niż w sytuacji, gdyby Developerzy codziennie oceniali, ile pracy zostało do wykonania. Planując Sprint ciężko przewidzieć dobrze, jak będzie w szczegółach wyglądał jego przebieg; to oznacza, że niektóre z wycen czasochłonności będą mocno nietrafione. Oczywiście można tego uniknąć, codziennie przeszacowując każde z nieukończonych zadań, ale to byłoby jeszcze trudniejsze niż robienie tego na poziomie PBI (których jest przecież zdecydowanie mniej).

Po czwarte i najważniejsze, ten sposób użycia wykresów spalania wymaga posłużenia się zadaniami, a to wpływa na przebieg Planowania Sprintu. Konieczne jest tworzenie zadań, bo bez nich nie da się sporządzić początkowego wykresu spalania. Co więcej, Developerzy będą niejako zmuszeni do przewidzenia większości zadań, jakie trzeba będzie wykonać – również dla tych PBI, które na pewno nie będą realizowane na początku Sprintu (ze względu na zależności lub priorytety). Wartość takiego planu będzie mierna, a skutecznie wydłuży i utrudni to samo Planowanie Sprintu.

Jest i piąty problem: Developerzy, którzy monitorują postęp prac w Sprincie poprzez analizowanie listy zadań, na jakie rozłożyli poszczególne elementy Backlogu Produktu, mają tendencję do realizowania zbyt wielu rzeczy naraz. Inaczej mówiąc, zamiast skupić się zespołowo nad jednym lub dwoma PBI, ukończyć je i zabrać się za kolejne, każdy Developer zacznie wykonywać takie zadania, które są maksymalnie zgodne z jego kompetencjami. W efekcie może okazać się, że każdy z nich zajmuje się innym PBI. Z wielu względów jest to niekorzystne, ale warto wspomnieć jeden: wszystkim może się wydawać, że póki nieźle idzie realizacja zadań, to sprawy w Sprincie mają się dobrze, choć w rzeczywistości mogą robić nie te zadania, które aktualnie powinny być robione. Skupienie na PBI, zamiast na zadaniach, pozwala ograniczyć takie ryzyko.

Do czego więc nadają się wykresy spalania?

Prosta odpowiedź: na pewno nie do monitorowania postępów prac i dlatego dojrzałe Zespoły i organizacje posługują się innymi narzędziami. Jeśli już nie ma innego wyjścia i z jakiegoś powodu trzeba się posłużyć burndown chartem, najlepiej trzymać się z daleka od obrazowania na nim liczby zaplanowanych zadań, tylko zadbać o minimalną bodaj widoczność postępu w realizacji nośników wartości (w Scrumie będą to elementy Backlogu Produktu).

Czego użyć w zamian?

Niezmiennie źródłem dobrych praktyk jest Kanban, który definiuje cztery podstawowe miary przepływu. Ich wizualizacje w postaci wykresów lub diagramów, w połączeniu z tablicą kanbanową, pozwalają dużo lepiej ocenić postęp prac i ustalić priorytety na każdy dzień, niż jakikolwiek burndown chart.

Przykładowy Zespół Scrum, rozważany wcześniej, mógłby użyć wykresu starzenia się jednostek pracy (ang. work item aging chart), na którym widziałby nie tylko to, jakie PBI są aktualnie realizowane, ale też jak długo trwa praca nad każdym z nich i w jakim jest aktualnie stanie.