Jedną z metod wizualizacji postępów sprintu jest narzędzie zwane wykresami wypalenia (ang. burndown charts). W zależności od potrzeb możemy zastosować wykresy wypalenia oparte na zadaniach bądź na tzw. story points. Z mojego doświadczenia wynika iż lepszą wizualizację daje nam wykres wypalenia po zadaniach, jest łatwiej zarządzalny i ukazuje klarowność zadań podczas iteracji.
Jednak zanim przejdę do opisu metody, odpowiedzmy sobie na pytanie po co stosowana jest owa technika ?
- Pokazuje odchylenia względem idealnej linii postępu działań w ramach iteracji. Mając zobrazowane te dane możemy wyciągać wnioski podczas sprint retrospective co do istotnych momentów sprintu.
- Szybko ukazuje ryzyka nie wykonania założonych prac na konkretny moment czasowy, zespół widząc te dane otrzymuje w porę sygnał aby przyśpieszyć pracę, działanie proaktywne.
- Prezentuje status sprintu, informacja czy zadania podczas iteracji są wykonywane właściwie, wolniej lub szybciej niż zakładano
Aby mieć dane które wykorzystamy do budowy wykresów wypalenia w opaciu o zadania, musimy do każdego user story dopisać zestaw zadań do wykonania, a właściwie podzielić dane user story na zadania. W skład zadań mogą wejść: development, testy, integracja z istniejącym kodem, przeglądy wymagań z produkt ownerem lub doprecyzowanie designu. Zidentyfikowane z zespołem i przydzielone do osób odpowiedzialnych zadania należy spisać w jakimś miejscu np. excel oraz przypisać do każdego z zadań orientacyjną liczbę godzin potrzebnych do realizacji. Kolejnym krokiem jest sprawdzanie każdego dnia ile godzin pozostało do wykonania w ramach każdego zadania. Chodzi tu o to aby widzieć ile godzin zostało do pełnej realizacji zadania a nie wliczać w to ilość spędzonego na zadaniu czasu. Oczywiście może się zdarzyć że czas potrzebny na realizację zadania wydłuży się lub nawet będzie potrzeba dodania nowego zadania. Wówczas taki niezidentyfikowany wcześniej task dodajemy to listy zadań i zaczynamy go wliczać do pozostałego czasu realizacji od momentu wykrycia. W momencie kiedy nie mamy pozytywnego feedbacku ze strony zespołu, scrum master komunikuje się z odpowiednimi osobami w celu usunięcia przeszkód, dodatkowego wsparcia, a jeżeli problem okaże się poważny, może dojść wręcz do negocjacji wymiany całego user story z produkt ownerem. Aby w porę dostrzec problem trzeba być na bieżąco z komunikacją w zespole i dbać o poprawną dzienną aktualizację danych na wykresie.
Na koniec każdego dnia lub po skończeniu zadania należy zaktualizować liczbę pozostałych tasków. Przykładowo jeśli zadanie numer 5 zostało ukończone pod koniec 3 dnia, na początku dnia 4, wśród pozostałych zadań nie ma już nic na temat zadania numer 5. Następnie bazując na zsumowanej liczbie czasu pozostałego do realizacji pozostałych zadań tworzony jest wykres. Na wykresie powstaje punkt który przyrównujemy do punktu wykresu idealnego czyli tam gdzie teoretycznie powinniśmy być w danym dniu, który powstaje z podziału liczby godzin przez kolejny dzień sprintu. Przeliczając dane w cyklu dziennym od razu otrzymujemy informację na temat stanu realizacji sprintu. Widzimy czy idziemy zgodnie z trendem czy pojawiają się na horyzoncie potencjalne problemy.
Do prawidłowej estymacji, każde zadania powinno być wykonywalne w ramach jednego dnia, jeśli zadania są większe wówczas należy je podzielić na mniejsze. Mając wystarczająco małe zadania członkowie zespołu komunikują je podczas spotkania stand up otwierającego dzień i starają się je wykonać do końca dnia.
Koordynowanie czasem zespołu jest bardzo istotnym czynnikiem, wykres wypalenia daje ogólny obraz sprintu i w prosty sposób ukazuje informację czy scrum master ma „powody do zadowolenia” czy dostaje informację aby w porę zareagować na pojawiające się problemy.
0 komentarzy