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:

  1. Mierzenie rezultatów pracy Zespołu Developerskiego
  2. Monitorowanie employees user experience Developerów
  3. 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.

Scrum Guide | 11. Jakie statystyki i metryki powinien śledzić Scrum Master? caroline becker avatar 1background

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ść.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?