Celem stosowania wykresów spalania jest dostarczanie Zespołowi Scrum’owemu (Scrum Team) aktualnych informacji na temat ilości pracy, jaka pozostała do wykonania przed końcem sprintu. Głównym beneficjentem tworzenia i aktualizowania wykresu spalania jest Zespół Deweloperski (Development Team), który dzięki wizualizacji postępów swojej pracy może dokonywać usprawniać swoją organizację.

Wykresy spalania są niezwykle prostym narzędziem. Mimo to, można na ich podstawie wyciągać cenne wnioski dotyczące pracy zespołowej. Wymaga to utrzymywania rygoru Daily Scrum, który jest podstawowym źródłem danych dla wykresu spalania, a także dyscypliny Development Team’u. Dobry Scrum Master dba o codzienne aktualizacje wykresu spalania, a także o jego powszechną znajomość i zrozumienie w całym Scrum Team’ie. Zdecydowanie warto dbać o jakość wykresu, ponieważ w określonych sytuacjach może się on stać podstawą do negocjacji z Właścicielem Produktu (Product Owner).

Tworzenie Wykresu Spalania

Do przygotowania wykresu spalania niezbędny jest Rejestr Sprintu (Sprint Backlog), zawierający informacje o szacowanej ilości pracy w całym sprincie, czyli Pracy Zaplanowanej (Estimated Velocity). Szacowanie jest jednym z najważniejszych zadań stojących przed Development Team’em podczas Planowania Sprintu, ponieważ od niego zależy ile elementów Rejestru Produktu (Product Backlog) wejdzie do Sprint Backlog’u. Jest to szczególnie trudne dla organizacji dopiero zaczynających pracę ze Scrum’em, ponieważ nie mają one informacji z poprzednich projektów, dotyczących relacji pomiędzy Pracą Zaplanowaną, a Pracą Wykonaną (Actual Velocity). Henrik Kniberg radzi w takich wypadkach przyjmować wartość Współczynnika Skupienia (Focus Factor) równą 70%.

Jeżeli Sprint Backlog jest gotowy, można przystąpić do tworzenia Wykresu Spalania. Dwie najważniejsze informacje, potrzebne na początku, to:

  • Praca Zaplanowana (liczba Story Points, jakie wziął na siebie Development Team)
  • Długość sprintu

Posiadając te dane można wykreślić układ współrzędnych, który posłuży za kanwę Wykresu Spalania.

1-4

Do sporządzenia powyższego przykładowego wykresu spalania przyjęto, że Zaplanowana Praca wynosi 14 Story Points, a czas trwania Sprintu to 14 dni. Weekendy zostały wykluczone z wykresu, jako dni potencjalnie poświęcane na inne zajęcia niż praca. Oś Y reprezentuje Pracę, a X czas sprintu. Linia trendu, nazwana „Drogą do sukcesu” obrazuje w jakim tempie powinny postępować prace, żeby cel Sprintu został osiągnięty i wszystkie przyjęte do Sprintu elementy Product Backlog’u zostały wykonane na czas.

Warto zwrócić uwagę, że Wykres Spalania nie określa żadnego typu współzależności pomiędzy wykonywanymi przez Development Team zadaniami. Dzięki temu, nie zostaje złamana zasada samoorganizacji, zgodnie z którą zespół sam decyduje to tym jak wykona Zaplanowaną Pracę.

Wykres Spalania jest uzupełniany codziennie, po Daily Scrum’ie. Development Team dostarcza informacji o nowych szacunkach, a także określa, które elementy Sprint Backlog’u są już zakończone. Dzięki tym danym Scrum Master może obliczyć jaka liczba Story Points pozostała do wykonania i zaznaczyć to na wykresie.

2-3

Powyższy schemat pokazuje potencjalny Wykres Spalania, jaki został wygenerowany podczas czternastodniowego Sprintu. Do wyznaczenia czerwonej krzywej „Pozostała Praca” Scrum Master musi po każdym Daily Scrum’ie zapytać Development Team ile pracy (w Story Points) zostało do ukończenia wszystkich elementów Sprint Backlog’u. Uzyskaną odpowiedź zaznacza na Wykresie Spalania. UWAGA! Wykres Spalania zawsze pokazuje ile pracy pozostało do zrobienia, a nie ile zostało zrobione!

Interpretacja Wykresu Spalania

Powyższy wykres pokazuje sytuację idealną, czyli taką, w której Development Teami ukończył wszystkie przyjęte do Sprintu elementy Product Backlog’u, a podczas pracy nie napotykał na anomalie. Wskazują na to niewielkie odchylenia od „Drogi do sukcesu”, która pokazuje jak w przybliżeniu powinny postępować prace, żeby ukończyć wszystkie zadania w zaplanowanym czasie.

Scrum Master musi być czujny i odpowiednio reagować na odchylenia pojawiające się na Wykresie Spalania. Wprawdzie Development Team organizuje się samodzielnie, ale zadaniem Scrum Master’’a jest czuwanie nad tym, żeby odpowiednio reagował na niepokojące sygnały płynące z Wykresu Spalania.

3-4

Wykres zamieszczony powyżej prezentuje dwie potencjalne sytuacje, jakie mogą wystąpić podczas Sprintu. Pierwsza z nich, zaznaczona czerwoną krzywą, jest bardzo niebezpieczna, ponieważ wskazuje na to, że Development Team nie zrealizuje zadeklarowanego zakresu zadań. Może ona wystąpić, jeżeli:

  • Zespół źle oszacował czas potrzebny na wykonanie zadań (wznoszenie się wykresu może oznaczać aktualizację szacunków, również spowodowaną nowymi zadaniami od Product Owner’a)
  • Zespół nie potrafi się zorganizować, występują problemy w pracy zespołu
    Druga sytuacja również nie jest korzystna. Może wskazywać na to, że Development Team wziął na siebie zbyt mało zadań (na przykład z powodu zbyt ostrożnego szacowania czasu) i powinien negocjować z Product Owner’em przyjęcie kolejnych elementów Product Backlog’u do Sprintu. Możliwe jest także, że  Development Team zaczął prace nad mniej ważnymi zadaniami i zaniedbuje priorytety. Scrum Master może zbadać przyczyny zaburzenia wykresu analizując aktualny stan Sprint Backlog’u.

Wnioski

Wykresy Spalania są prostym, a zarazem potężnym narzędziem w rękach dobrego Scrum Master’a. Pozwalają na odpowiednio szybką adaptację Development Team’u do zmian zachodzących w projekcie, zapobiegają konfliktom z Product Owner’em na koniec Sprintu, a także motywują Development Team do coraz lepszej samoorganizacji. Scrum Master musi dbać o aktualność i przejrzystość Wykresu Spalania oraz zapewniać jego powszechną dostępność.

Kiedy Wykres Spalania to za mało

Wykresy Spalania pozawalają monitorować postępy Development Team’u, ale nie są idealną metodą na uzyskiwanie wiarygodnych informacji o skuteczności zespołu i jej przyczynach. Poniżej prezentuję metodę, którą stworzyłem opierając się na pomysłach praktyków i Guru SCRUM’a, znakomicie działającą podczas dłuższych projektów.

CASE STUDY

Kasia, jeden z PSPO (Professional Scrum Product Owner) firmy Mobitech, doprowadziła do podpisania kontraktu z dużą firmą szkoleniową na dostarczenie oprogramowania mobilnego służącego do prowadzenia interaktywnych warsztatów sprzedażowych. Podczas rozmów z klientem dobrze poznała założenia projektu i opracowała wstępny zarys Product Backlog’u . Po dyskusji z zespołem, który zajmie się realizacją projektu, ustaliła, że przewidywalny zakres projektu to 400 Story Points. Klient chce dostać oprogramowanie przed upływem dwudziestu tygodni.

Rafał, PSM (Professional Scrum Master) wyznaczony do czuwania nad projektem, obliczył, że w trakcie każdego z 10 dwutygodniowych Sprintów zespół będzie musiał realizować 40 Story Points. Biorąc pod uwagę, że przeciętny Focus Factor zespołów w Mobitech kształtuje się na poziomie około 70%, ustalił, że Sprinty będą wymagały zespołu dysponującego około 60 Man Days na 10 dni. Przy pełnej dyspozycyjności zasobów ludzkich Mobitech’u, daje to 6 osobowy zespół. Taką właśnie liczebność Rafał zaproponował zarządowi Mobitech’u.

Po 8 sprintach zespół ma do zrealizowania jeszcze 180 Story Points, czyli średnio 90 w każdym z dwóch pozostałych sprintów.

Stosując „tradycyjny” wykres spalania całego projektu, czyli Release Monitoring/Burndown Chart, SCRUM MASTER otrzymuje następujący obraz projektu.

4-2

Bez sięgania po dodatkowe informacje, można wnioskować, że w 3 i 6 sprincie „coś” się stało. Jedna z możliwości to niedoszacowanie zadań, jakie wziął na siebie Development Team. Wskazuje na nią wznosząca się krzywa, która oznacza, że po Sprincie pozostało więcej Story Points niż przed nim. Druga opcja, to „sabotaż” Product Owner’a, który dołożył w trakcie Sprintu dodatkowe Story Points do Product Backlog’u. Nie da się podać prawdziwej przyczyny bez analizy dodatkowych informacji.

Dużo mogłaby wnieść analiza Burndown Charts z 3 i 6 Sprintu. Jeżeli nie wskazują one na złą samoorganizację Development Teamu’u, to prawdopodobnie wina leży po stronie Product Owner’a, który rozszerza zakres projektu.

Pytania, na jakie musi odpowiedzieć Scrum Master to:

  1. Co jest przyczyną niekorzystnego przebiegu wykresu w sprintach 3 i 6? (Złe szacowanie zespołu, a może dodatkowe zadania od PSPO?)
  2. Jeżeli to zespół źle szacuje, jakie podjąć działania zaradcze?
  3. Jeżeli za dodatkowe Story Points odpowiada Product Owner, to ile punktów zostało dodanych a ile spalonych? (Jeżeli PSPO dodał więcej punktów niż odległość wykresu spalania od idealnej ścieżki spalania, to zespół spisuje się rewelacyjnie. Jeżeli nie, to zespół sobie nie radzi)
  4. Czy do zespołu powinna dołączyć kolejna osoba, a może trzeba pracować nad wydajnością zespołu?

Wykres zamieszczony poniżej pozwala rozwiać wątpliwości Scrum Mastera i podjąć właściwe decyzje. Wykres wprowadza dwie innowacje.

5-2

Pierwsza to dodatkowa oś pionowa, odzwierciedlająca Focus Factor Development Team’u. Jest to wskaźnik zaczerpnięty od Henrika Kniberga (Scrum and XP from the Trenches) pokazujący relację pomiędzy Available Man Days na dany Sprint, a Actual Velocity (spalone Story Points) z danego Sprintu. Im wyższa jego wartość tym wyższa wydajność zespołu. Np. jeżeli zespół dysponuje 10 Man Days a spalił 7 Story Points, to znaczy, że pracował z wydajnością 70%. Jeśli w kolejnych Sprintach wskaźnik utrzymuje się na podobnym poziomie to znaczy, że zespół pracuje równo. Systematyczny wzrost oznacza, że Development Team coraz lepiej się samoorganizuje. Spadający wskaźnik sygnalizuje występowanie problemów. Warto zauważyć, że wskaźnik jest niezależny od tego, czy Product Owner dokłada zadania, czy redukuje zakres. Focus Factor zawsze pokazuje relację pomiędzy potencjałem zespołu a tym co osiągnął!

Drugą innowacją jest krzywa idealnego spalania Story Points w projekcie. Wprowadzenie krzywej w miejsce odcinka umożliwia modyfikowanie idealnej ścieżki o zmiany zakresu projektu dokonywane przez Product Owner’a. Można dzięki niej śledzić prawdziwe, aktualne odchylenia pracy zespołu od ideału, zamiast analizować fikcyjne odchylenia od ścieżki wyznaczonej na początku projektu. Na krzywej nie są zaznaczane zmiany szacunków dokonanych przez Development Team w odniesieniu do początkowego Product Backlog’u. Dzięki temu można obserwować zmiany wynikające z jakości pracy zespołu niezależnie od modyfikacji zakresu wprowadzanych przez Product Owner’a. (Jeżeli Product Owner nie ingeruje w Sprint Backlog, to krzywa idealnego spalania pozostaje odcinkiem).

Analiza wykresu odpowiada praktycznie na wszystkie pytania zadane przez Scrum Mastera.

  • Za odchylenie w Sprincie 3 odpowiedzialny jest na pewno Product Owner ponieważ podniosła się idealna ścieżka spalania. Wskazuje to na rozszerzenie zakresu projektu i zmianę tempa spalania (kąt nachylenia krzywej) prowadzącego do realizacji projektu w terminie. Niewykluczone, że również zespół nie doszacował części zadań. Warto przeanalizować dodatkowo Wskaźnik Dokładności Szacowania Zadań ( Task Estimation Accuracy Metric = Estimated Velocity / Actual Velocity + Remaining Story Points ). Wskaźnik dokładnie opisuje Ilan Goldstein na swoim blogu (link na końcu artykułu). W skrócie, wartości mniejsze od 1 sygnalizują, że zespół robi więcej niż zakładał na początku Sprintu. Większe od 1 oznaczają, że Development Team przeszacowuje swoje możliwości lub nie doszacowuje rzeczywistą czasochłonność zadań. Gdyby jednak niedoszacowanie zadań przez zespół było znaczące, to wykres spalania poszedłby w górę dużo bardziej niż ścieżka idealnego spalania.
  • Co bardzo ważne, Focus Factor zespołu w 3 Sprincie się nie zmienił, co oznacza, że zespół dobrze wykonuje swoją pracę, a zaburzenie krzywej spalania to efekt działań Product Owner’a.
  • Pomimo utrzymania stałej wydajności, krzywa spalania coraz bardziej oddala się od idealnej ścieżki. Widać to dzięki zmianie kąta jej nachylenia. Żeby zespół zdążył z terminową realizacją projektu niezbędne jest zwiększenie wydajności zespołu lub dodanie Available Man Days, przez rozszerzenie składu Development Team’u. W pierwszej kolejności Scrum Master powinien przeanalizować Impediment Backlog (Rejestr Przeszkód), żeby wyeliminować potencjalne bariery pracy zespołu, obniżające jego wydajność.
  • Teoretycznie podobna zmiana po Sprincie 6, okazuje się mieć zupełnie inne przyczyny niż wcześniejsze odchylenie. Dzięki wykresowi można zauważyć, że Product Owner dodał stosunkowo niewiele Story Points (30) do projektu. Mimo to, krzywa spalania poszła bardzo w górę. Winę ponosi za to słaba wydajność zespołu, który zanotował bardzo niski poziom Focus Factor. Najprawdopodobniej wydarzyło się coś niekorzystnego wewnątrz Development Team’u. Sprawa wymaga bliższego przyjrzenia się.
  • Bardzo ciekawe informacje pokazuje kształt wykresu po Sprincie 7. Wykres standardowy nie wskazywał na nic nadzwyczajnego. Tymczasem kolejne załamanie się idealnej ścieżki spalania pokazuje, że Product Owner znów dodał Story Points do zakresu projektu. Pomimo to, krzywa spalania nie zmieniła swojego kąta. Oznacza to, że Development Team wyrobił swoją normę 40 Story Points oraz dodatkowe 30, dodane przez PSPO. Potwierdza to bardzo wysoki poziom Focus Factor. Scrum Master musi nagrodzić zespół.

Dodatkowe wskazania wykresu, który nazwałem Improved Release Monitoring Chart pozwalają dużo dokładniej śledzić przebieg projektu i reagować w odpowiedni sposób na zachodzące w nim zdarzenia. Jego tworzenie jest bardzo proste i nie wymaga od Scrum Mastera praktycznie żadnych dodatkowych nakładów pracy. Wykres stanowi w rękach PSM’a dodatkowy atut np. podczas rozmów z zarządem, kiedy trzeba negocjować dodanie kolejnej osoby do zespołu lub nagrody dla Development Teamu (Sprint 7).

Poza Improved Release Monitoring Chart warto śledzić również proste wskaźniki liczbowe. Jedną z ważnych wartości jest przeciętna wartość spalania zespołu (Average Velocity). Jej obserwacja i porównywanie z zakresem projektu liczonym w Story Points pozwala na bieżąco określać prognozowane opóźnienie projektu. W omawianym przykładzie Average Velocity wynosiło po 4 Sprincie 40 Story Points. Przy zakresie wynoszącym 450 było jasne, że bez zmiany tej wartości projekt opóźni się o około 1 Sprint. Wyjściem była praca nad Focus Factor, albo dodanie nowego członka zespołu. Brak reakcji na odchylenia sprawił, że kolejne zmiany w projekcie zaowocowały zwiększeniem zakresu projektu do 510, przy niezmiennym niemal poziomie Average Velocity, który w tamtym momencie wynosił nieco ponad 41 (wyłącznie dzięki rewelacyjnemu 7 Sprintowi). W rezultacie spodziewane opóźnienie zbliżyło się do 3 Sprintów, czyli 6 tygodni!

Linki:

PODZIEL SIĘ
Rafał Łabędzki
Działalność w formie projektowej jest, moim zdaniem, jedną z najbardziej naturalnych form współpracy między ludźmi. Na zarządzanie projektami staram się patrzeć nieszablonowo. Zadając czasem niewygodne pytania, próbuję szukać rozwiązań pomagających zespołom i menedżerom w ich codziennej pracy.

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ