Jakie statystyki i metryki powinien śledzić Scrum Master?

Po co Scrum Masterowi statystyki i metryki? Przede wszystkim po to, aby sprawdzać, czy jego metody pracy nad przewidywalnością rezultatów i poprawą efektywności zespołu są skuteczne. Lecz także po to, aby na bieżąco śledzić, jak jego działania wpływają na Zespół Developerski. Czyli jak kształtują doświadczenie użytkownika pracownika (employees user experience, EX). Jakie zatem statystyki i metryki powinien śledzić Scrum Master?

Jakie statystyki i metryki powinien śledzić Scrum Master – omówione zagadnienia:

Mierzenie rezultatów pracy Zespołu Developerskiego
Monitorowanie employees user experience Developerów
Podumowanie

Mierzenie rezultatów pracy Zespołu Developerskiego

Najczęściej używanymi wykresami, jakie powinien obserwować Scrum Master, są te opisujące tempo i przepływ wykonywania zadań. Są to wykres spalania, Burnup Chart, oraz Cumulative Flow Chart. Służą one do mierzenia zarówno rozwoju produktu, jak i efektywności zespołu. Każdy z nich pozwala podejść do tych zagadnień nieco inaczej, dlatego warto używać ich łącznie. Mogą one służyć do oceny postępów w różnej skali. Zarówno tych dokonanych podczas Sprintu, jak i całego procesu powstawania produktu.

Burndown Chart

Wykres spalania, pokazuje Scrum Masterowi i Zespołowi Developerskiemu, ile pracy wykonano, a ile zostało jeszcze do wykonania. Na osi X przedstawiony jest czas jaki pozostał na wykonanie pracy. Natomiast na oś Y nanoszona jest ilość pracy pozostałej do wykonania, która została zaplanowana w Backlogu Sprintu lub Backlogu Produktu.

Burndown chart pozwala określić Prędkość Zespołu Developerskiego, której również poświęcimy osobny artykuł. Tutaj wspomnimy tylko, że jest to uśredniona ilość pracy wykonywanej w czasie jednego Sprintu.

To proste narzędzie pozwala Scrum Masterowi nie tylko przekonać się, jak wydajnie pracuje zespół. Pomaga też odpowiedzieć na pytania:

Jaka część pracy została już ukończona?
Jak wiele zadań zostało do wykonania?
Jak długo będzie trwała praca nad Produktem?

Scrum Master korzystając z Wykresu Spalania musi pamiętać o tym, że nie jest to jedyne narzędzie pozwalające na ocenę postępów pracy zespołu przez statystyki. Sprawdza się on najlepiej w przypadku projektów, w których zakres prac jest stały i znany. Gorzej sprawdzi się w przypadku tworzenia bardzo innowacyjnych rozwiązań z nowym Klientem. Wtedy ilość pracy do wykonania w całym projekcie – czyli treść Backlogu Produktu – może znacząco zmieniać się w trakcie realizacji utrudniając korzystanie z Burndown Chart.

Burnup chart

Można powiedzieć, że Burnup Chart jest odwróceniem omówionego powyżej wykresu spalania (Burndown chart). Tutaj również na na osi Y zaznaczona jest ilość pracy pozostałej do wykonania. Natomiast oś X pokazuje czas realizacji wyrażony w ilości Sprintów albo w datach.

Scrum Master wykorzystuje jednak Burnup Chart w nieco innym celu. Pozwala on bowiem nie tylko ocenić postęp prac nad produktem i postępy Zespołu. Metryka ta służy także ocenie tego, jak z upływem czasu zmienia się zakres prac w projekcie. Dlatego sprawdza się dobrze w projektach o zmiennym zakresie.

Burnup Chart jest także narzędziem planowania, które staje się z czasem coraz skuteczniejsze. Pozwala odpowiedzieć na pytanie, ile pracy szacunkowo wykona Zespół Developerski w następnym Sprincie.

Cumulative Flow Diagram

Trzeci rodzaj wykresu bardzo przydatnego w pracy Scrum Mastera z Zespołem Developerskim to Cumulative Flow Diagram. Pozwala on ocenić, jak stabilne jest tempo i wydajność pracy Zespołu Developerskiego. Układ jego osi jest taki samo jak w Burnup Chart, dlatego często określany jest jako jego bardziej złożona wersja.

Cumulative Flow Diagram służy jednak nie tylko do określania ilości zadań wykonanych w danym okresie czasu. Uwzględnia także ilość zadań, które oczekują w kolejce na wykonanie. Dzięki temu pozwala na diagnozę tzw. „wąskich gardeł” (bottlenecks), czyli momentów procesu, które spowalniają powstawanie produktu.

Ta właśnie funkcja diagnostyczna czyni go jedną z najbardziej przydatnych metryk w rękach Scrum Mastera. Pozwala bowiem przeorganizować pracę w taki sposób, aby inaczej rozłożyć siły Zespołu Developerskiego i uniknąć przestojów.

Statistics and metrics the Scrum Master should track

Monitorowanie employees user experience Developerów

Regularne i skrupulatne prowadzenie oraz analiza statystyki jest bardzo ważną częścią pracy skutecznego Scrum Mastera. Musi on jednak pamiętać przede wszystkim o employees user experience Developerów, czyli sposobie w jaki odbierają oni pracę w Scrum Team. O tym decyduje jednak nie jakość metryk, lecz sposób, w jaki Scrum Master z nich korzysta.

Jeśli statystyki są prowadzone zgodnie z zasadami Scruma – są przejrzyste, jawne i zrozumiałe dla zainteresowanych Developerów – mogą być sposobem na motywowanie zespołu do bardziej wydajnej pracy lub nagradzania go za świetne rezultaty. Statystyki mogą być jednak używane jako narzędzie służące do wywierania presji na Zespół Developerski. Wtedy ich wskazania stają się generatorem oskarżeń i pretensji. Mogą przyczyniać się do pogarszania morali zespołu i psucia praktyki pracy zespołowej.

Drugim ważnym czynnikiem employees user experience Developerów, o jaki musi zadbać Scrum Master pracujący z narzędziami do analizy statystyki, jest sposób wykorzystania jego własnego czasu. Scrum Master musi mieć bowiem wystarczającą ilość czasu, żeby zająć się Zespołem Developerskim. Z tego powodu w przypadku dużego projektu, warto rozważyć włączenie do Scrum Team dodatkowej osoby. Będzie ona pełniła rolę menadżera projektu i zajmowała się prowadzeniem metryk. Dzięki temu odciąży Scrum Mastera – a także do pewnego stopnia Product Ownera – z wykonywania zadań które odciągają go od pracy z Zespołem Developerskim.

Podsumowanie

Scrum Master powinien śledzić podstawowe statystyki opisujące pracę Zespołu Developerskiego. Ich umiejętna interpretacja zwiększa szansę na szybkie zauważanie problemów pojawiających się w pracy Zespołu i reagowanie na nie. Jednak ważniejsze niż prowadzenie wykresów jest to, co robi z nimi Scrum Master. Nie powinien bowiem traktować metryk jako narzędzi służących do oceny Zespołu, a raczej traktować je jako przydatną pomoc w motywowaniu Zespołu i diagnozowaniu własnego sposobu działania. Metryki będą bowiem przydatnymi narzędziami jedynie wtedy, gdy pozwolą na doskonalenie pracy Zespołu i procesów doskonalenia Produktu.

Przeczytaj również: Współpraca Scrum Mastera z Product Ownerem

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty