wykres spalania co to jest blog post

Wykres Spalania (Burndown Chart) – co to jest i jak go przygotować

Agile

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 ⬇️ 😎

 

Przykładowy Wykres Spalania

Przykładowy Wykres Spalania

 

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

przykład wykresu spalania burndown chart 1

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ś

przykład wykresu spalania burndown chart 2

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

przykład wykresu spalania burndown chart 3

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.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *