Wykres spalania ma wiele zalet. Nie bez powodu jest jednym z głównych narzędzi metrycznych używanych w Scrum. Jest łatwy do stworzenia, skalowalny i czytelny. Ma jednak także wady, które sprawiają, że nie jest narzędziem uniwersalnym.
O tym czym jest, jak tworzyć i interpretować wykres spalania pisaliśmy w poprzednich artykułach. Dziś natomiast skoncentrujemy się na zaletach i wadach tego rozwiązania. Większość z nich nie kryje się jednak w samym prostym wykresie. Wiążą się one raczej ze sposobami wykorzystywania wykresu spalania do motywowania Zespołu Developerskiego, opisywania rezultatów jego pracy i wzmacniania samoorganizacji.
Wykres spalania pozwala w czytelny sposób zwizualizować postęp prac w projekcie. To właśnie czytelność i prostota wykonania decydują o jego ogromnej popularności. Dlatego warto, by wykres spalania był nie tylko na bieżąco aktualizowaną metryką ukrytą w cyfrowym narzędziu do zarządzania projektem. Jeśli to tylko możliwe, warto by stał się punktem odniesienia dla Zespołu Developerskiego widocznym w fizycznym miejscu pracy. Czy to w formie wyświetlanej na ekranie wizualizacji, czy ręcznie narysowanego szkicu.
Przejrzystość wykresu spalania może sprawić, że stanie się on narzędziem motywującym Zespół Developerski do wydajnej pracy. Osiągnięcie w każdym Sprincie punktu „zero” może stać się ambicjonalnym celem Zespołu, za który są przyznawane nagrody – zgodnie z zasadami biznesowej gamifikacji.
Widoczność aktualnego i ciekawie prowadzonego wykresu spalania może również budować ducha współpracy i samoorganizacji. Metryka jest bowiem miarą zespołowej pracy. Nie widać na niej, kto dokładnie wykonał – lub nie wykonał – zaplanowane zadania, a jedynie osiągnięte rezultaty.
To Developerzy decydują, ile zadań wykonają w danym Sprincie. Im bardziej doświadczony jest Zespół, z tym większą trafnością powinien przewidywać swoje działania. Zaś wykres spalania odzwierciedla realny przebieg Sprintu.
Zaletą wykresu spalania jest więc nie tyle mierzenie obiektywnej ilości wykonanej pracy, ile stosunku zaplanowanych do realnie wykonanych zadań. Dzięki temu Developerzy stopniowo uczą się ich planowania i mogą coraz dokładniej szacować swoje możliwości oraz eliminować powtarzalne błędy.
Jedną z istotnych zalet wykresu spalania są wyniki, jakie można uzyskać dzięki połączeniu go z innymi narzędziami. Mogą być to narzędzia służące do:
Przykładowo, w tym ostatnim przypadku wykorzystanie wykresu spalania w skali Projektu pozwala na porównanie planowanego i rzeczywistego budżetu całego przedsięwzięcia.
Pomimo wszystkich przedstawionych powyżej zalet, wykres spalania może stać się źródłem nieporozumień w Zespole Developerskim. Często to, co nazywamy „wadami” wykresu spalania nie jest jednak spowodowane niedoskonałością narzędzia. Przedstawione poniżej problemy wynikają bowiem raczej ze sposobu używania wykresu spalania, niż z jego konstrukcji. Poniżej przedstawiamy wady, jakie mogą zakłócać obrazowanie w ten sposób postępów w pracy Zespołu Developerskiego.
Wykresy nie mogą stanowić absolutnej miary postępu prac zespołu. Są to tylko narzędzia, które mogą być stosowane w różny, mniej lub bardziej umiejętny sposób. Może to zostać uznane za wadę (lub zaletę) nie tylko wykresu spalania, lecz także innych mierników efektywności zespołu.
Do stworzenia wykresu spalania potrzebne są dane wprowadzane przez ludzi. Innymi słowy, czas wykonania zadania jest wprowadzany do wykresu przez Developera. Mógł on nieco wydłużyć lub skrócić – przez nieuwagę lub chcąc poprawić sytuację zespołu. Developerom zdarza się też zapomnieć o logowaniu czasu pracy. Lub pozostawić włączony licznik. Sprawia to, że czas pracy wydłuża się do kilkunastu godzin. A po odkryciu pomyłki trudno jest odtworzyć jego realny przebieg.
Backlog Sprintu nie powinien być modyfikowany po rozpoczęciu Sprintu. Jednak w praktyce dość często zdarzają się takie zmiany. Wynikają one ze zmieniających się wymagań Interesariuszy. Albo nieprzewidzianych wcześniej problemów, na jakie trafiają Developerzy.
Sprawia to, że wykres spalania zostaje przeskalowany. Czas wykonania zadań pozostaje bowiem ten sam. Zwiększa się natomiast skala zadań pozostałych do wykonania. Może to sprawić mylne wrażenie, że Zespół Developerski nieprawidłowo zaplanował prace do wykonania w danym Sprincie. Albo też, że pracuje on zbyt wolno.
Zmiany w Backlogu Sprintu mogą też wynikać ze zbyt szybkiego ukończenia zadań, które zostały przewidziane do realizacji. W takiej sytuacji Zespół Developerski decyduje zwykle o zwiększeniu ilości zadań. To z kolei może skutkować nieukończeniem ich na czas. A także konfliktem wynikającym z nawarstwienia się zadań pozostałych z poprzedniego Sprintu z nowymi, zaplanowanymi do wykonania przez Interesariuszy i Product Ownera.
Duże zmiany w Backlogu Produktu mogą zaburzać kształt wykresu spalania. A tym samym mocno fałszować obraz postępów prac i efektywności Zespołu. Dzieje się tak, gdy pojawiają się nowe User Stories. Zaś te, które zbliżają się do fazy realizacji, są często rozbijane na mniejsze części. Zdarza się również, że Klient rezygnuje z niektórych funkcjonalności Produktu.
Dlatego podczas interpretacji wykresu spalania trzeba kierować się wiedzą i doświadczeniem w ocenie pracy Zespołu. A także brać pod uwagę zmienność Backlogu. Jeśli wykres spalania nie jest jedyną metryką stosowaną do oceny efektywności, inne wykresy, które opisaliśmy tutaj pozwolą dostrzec pełniejszy obraz postępu prac.
Wykres spalania może znacząco przyczyniać się do zwiększenia motywacji Zespołu Developerskiego. Stanowi bowiem miarę realnie wykonanej pracy w odniesieniu do planu. Natomiast jego połączenie z innymi narzędziami metrycznymi może być źródłem cennej wiedzy na temat pracy Zespołu i planowania Produktu.
Dzięki uważnemu stosowaniu zasad Scruma można uniknąć potencjalnych problemów z wykresem spalania . Najważniejsze będzie dostosowywanie używanych narzędzi do wyznaczania wykres spalania do realiów pracy Scrum Team. A także minimalizowanie zmian w Backlogu Sprintu i Produktu, o których więcej piszemy w tym artykule.
Zapoznaj się z kolejnym wpisem z tej serii: Tablice Kanban w Scrum i Scrumban
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ść.
Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…
Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…
Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…
Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…
Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…
“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…