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.
Zalety i wady wykresu spalania – omówione zagadnienia:
Wprowadzenie
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.
Zalety wykresu spalania
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.
Motywacja Zespołu Developerskiego
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.
Miara realnie wykonanej pracy
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.
Możliwość łączenia z innymi narzędziami
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:
- analizy pracy Zespołu Developerskiego
- wizualizacji postępu pracy nad Produktem
- szacowania budżetu projektu.
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.
Wady wykresu spalania
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.
„Czynnik ludzki”
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.
Zmiany w Backlogu Sprintu
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.
Zmiany w Backlogu Produktu
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.
Podsumowanie
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.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?