W tym poście dowiesz się co to jest Wykres Spalania, do czego może Ci się przydać i jak go zrobić.
Co to jest Wykres Spalania?
To wizualizacja stanu pracy w Sprincie – ile roboty za Wami i ile przed Wami. Podane w formie wykresu. Słowa nie są potrzebne, gdy ma się taki obrazek ⬇️ 😎
Po co zawracać sobie tym głowę?
Zespoły odnoszą się do niego na Daily. Wizualizacja ułatwia obserwację i zrozumienie. Wykres pomaga zobrazować to ile jeszcze zostało pracy, czy to co zaplanowaliście spalacie w dobrym tempie itd.
Wykres pomaga zauważyć pewne problemy. Przykładowo mówi coś o wrzutkach, które negatywnie wpływają na dostarczenie tego co zaplanowane – ich rozmiar i wpływ na Sprint będzie widoczny na takim Wykresie bardzo wyraźnie. O kilku innych sprawach też nam powie, ale o tym piszę nieco niżej.
Jak zrobić Wykres Spalania?
W sumie to nic skomplikowanego. Mam dla Ciebie nawet gotowca – sprawdź go tutaj.
Moja ulubiona forma to ręczna – na kartce papieru, z linijką, przy okazji Daily, burndown chart aktualizowany przez sam zespół :) Jednak dzisiaj, coraz częściej pracujemy rozproszeni w wielu lokalizacjach i musimy korzystać z narzędzi online. Czasem nawet ktoś woli narzędzie online 🤢
Do rzeczy. Potrzebujesz dwie osie – X i Y. Na osi X nanosisz kolejne dni Sprintu. Na osi Y nanosisz jednostki, w których mierzysz pracę pozostałą do zrobienia – w moich przykładach są to Story Pointsy (niektórzy używają np. liczby historyjek)
Krok po kroku
– na osi Y nanieś punkt początkowy, czyli liczba Story Points zaplanowana na dany Sprint (w przykładzie jest to 23.5)
– na osi X nanieś kolejne dni Sprintu (np. 1, 2, 3 albo daty)
– wyznacz linię idealną – zaczynasz w punkcie początkowym (X:0, Y: 23.5) i przeciągasz ją do ostatniego dnia, gdy praca jest w całości skończona (X: ostatni dzień, Y:0) – warto zrobić to innym kolorem niż linia faktycznego spalania
– na kolejnych Daily zaznaczaj liczbę punktów, które zostały Wam jeszcze do spalenia: przykład1 : spaliliście 2 punkty od wczoraj? to kreska o 2 punkty w dół; przykład2: dorzuciliście do sprintu coś o wartości 1 punkta? kreska w górę o 1 punkt; przykład3: dorzuciliście do sprintu 1 punkt i spalaliście 2? kreska o 1 punkt w dół
Jak czytać? Co mówi ten wykres? Przykłady
No dobra. Umiesz już robić piękne wykresy, ale co one Wam mówią?
Przykład 1: Gorący koniec Sprintu
Na tym przykładzie widzimy, że zespół zamyka historyjki tuż przed końcem Sprintu. Może to podpowiadać kilka rzeczy:
- kod czeka długo na testy czy akceptacje i np. dopiero na koniec Sprintu Product Owner daje znać, że zakodzone zmiany są OK
- przez dłuższy czas zespół mierzył się z jakimś blokerem technicznym,
- zespół lubi prokrastynować ;-)
Dlaczego taka sytuacja może być niedobra skoro udało się spalić wszystkie punkty? Ludzie lepiej i szybciej pracują, gdy mają równy rytm pracy. Zespół z równym tempem w dużo lepszy sposób kontroluje to co się dzieje u niego w Sprincie. Ponadto, może się okazać, że zmiany, które wprowadzamy spowodują jakieś błędy i nie będzie czasu na ich naprawę na sam koniec Sprintu.
Przykład 2: Ale szybko poszło, dorzućmy coś
Na tym przykładzie widzimy, że Deweloperzy szybko uporali się z większością pracy w Sprincie, a następnie zaczęli dobierać duże ilości pracy, których nie udało im się już ukończyć. Może to być spowodowane błędnym planowanie, przeszacowaniem rozmiaru historyjek itd. W drugim tygodniu Sprintu Deweloperzy zdecydowali się dobrać historyjki, ale te, których im się nie udało ukończyć zostają w Backlogu Produktu i tworzą „spady”. To dość kłopotliwa sytuacja dla całego zespołu, razem z Product Ownerem – na kolejnym planowaniu będą musieli zdecydować co zrobić z tak dużą ilością nieskończonych rzeczy i co jest ważniejsze: nowe rzeczy, jeszcze nierozpoczęte, które miały być zaplanowane na kolejny Sprint czy to co już zostało rozgrzebane?
Przykład 3: Sprint z wrzutkami
Na tym przykładzie zespół przyjmował do Sprintu sporo niezaplanowanych rzeczy, czyli tzw. wrzutek. Konsekwencją było nieukończenie rzeczy, które jak w przykładzie nr 2 zostaną nam na przyszłość. Niektóre zespoły świadomie przyjmują wrzutki, ale wiedzą, że je skończą przed zakończeniem Sprintu. Gorsza sytuacja jest, gdy np. Product Owner kiepsko ogarnia rzeczywistość produktowo-biznesową, źle komunikuje się z interesariuszami i przez to źle planuje prace – ciągle zmieniają się wymagania itd.
Może też się oczywiście okazać, że w trakcie pracy Deweloperzy trafili na dodatkowe informacje, które spowodowały, że trzeba zwiększyć zakres pracy. Tu warto zatem zastanowić się nad procesem Doskonalenia Backlogu i Planowania Sprintów – może coś na tym polu można zrobić, aby tempo pracy w Sprincie było równiejsze?
Pamiętajmy, że każda taka „wrzutka”, to dodatkowa konieczność synchronizacji wew. zespołu, kolejny kontekst lub informacja, które nasze mózgi muszą obsłużyć. A to ma swoje koszty – więcej w „Krótka gra, która pokazuje, że multitasking to zło” oraz „O marnowaniu #4 – Przełączanie między zadaniami i projektami”.
Dodatkowe uwagi
No i jeszcze dodam, że:
- fajnie jest zaznaczać istotne wydarzenia/problemy występujące w Sprincie – np. nie można zakończyć zadania, bo designer się rozchorował i nie mamy dostępu do plików graficznych, część roboty jest zablokowana do czasu rozwiązania problemu
- powyższe próby interpretacji Wykresu są jedynie przykładami. Rzeczywistość jest z reguły bardzo złożona, więc nie jest możliwe, aby takie narzędzie nam wszystko jednoznacznie powiedziało, dla każdego możliwego przypadku
- polecam też spróbować „Burnup Chart” (nie wiem jak to przetłumaczyć heh) – jest to wersja odwrócona, która pokazuje jak praca rośnie. Myślę, że może to mieć wymiar pozytywny – „wow, ale już dużo zrobiliśmy od początku Sprintu”
- w tym poście opisałem najpopularniejszy przykład użycia tego narzędzia – przez zespół deweloperski, w ramach pracy w Sprintach. Warto wiedzieć, że takie narzędzie też można wykorzystać do śledzenia dłuższych inicjatyw, które jednak są zamknięte w czasie – np. większe projekty. Chociaż dla nich pewnie często lepszy będzie Cumulative Flow Diagram.