Przewodnik po Scrumie | 11. Statystyki i wskaźniki, które Scrum Master powinien śledzić

Dlaczego Scrum Master potrzebuje statystyk i metryk? Po pierwsze, aby sprawdzić, czy jego metody pracy nad przewidywalnością wyników i poprawą efektywności zespołu są skuteczne. Ale także, aby śledzić, jak ich działania wpływają na Zespół Deweloperski. To znaczy, jak kształtują one user experience pracowników (UX). W tym artykule przedstawiamy statystyki i metryki, które Scrum Master powinien śledzić.

Statystyki i metryki ważne dla scrum mastera – spis treści:

1. Mierzenie wyników pracy Zespołu Deweloperskiego
2. Monitorowanie doświadczeń użytkowników przez pracowników Deweloperzy
3. Streszczenie

Mierzenie wyników pracy Zespołu Deweloperskiego

Najczęściej używane statystyki i metryki, które Scrum Master powinien śledzić, to te, które opisują tempo i przepływ wykonywania zadań. Są to wykres wypalenia, wykres wypalenia i wykres skumulowanego przepływu. Mierzy zarówno rozwój produktu, jak i efektywność zespołu. Każdy z nich pozwala podejść do tych zagadnień z innej perspektywy, dlatego warto pokazać je razem. Są poręcznymi narzędziami do oceny postępów w różnych skalach, zarówno podczas Sprintu, jak i całego procesu rozwoju produktu.

Wykres spalania

Wykres wypalania pokazuje Scrum Masterowi i Zespołowi Deweloperskiemu, ile pracy zostało wykonanej i ile pozostało do zrobienia. Oś X pokazuje czas pozostały do ​​zakończenia pracy. Oś Y pokazuje ilość pracy do wykonania, która została zaplanowana w Backlogu Sprintu lub Backlogu Produktu.

Wykres ten pomaga również określić Szybkość Zespołu Deweloperskiego, czemu też poświęcimy osobny artykuł. Tutaj tylko nadmienimy, że jest to przeciętna ilość pracy wykonanej podczas jednego Sprintu.

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

• Jaka część pracy została już zakończona?
• Ile zadań pozostało do wykonania?
• Jak długo zajmie opracowanie Produktu?

Korzystając z wykresu spalania, Scrum Master musi pamiętać, że nie jest to jedyne narzędzie do statystycznej oceny postępów zespołu. Najlepiej sprawdza się w projektach, w których zakres prac jest ustalony i znany. Nie sprawdza się przy tworzeniu bardzo innowacyjnych rozwiązań z nowym Klientem. Wtedy ilość pracy do wykonania w całym projekcie – czyli zawartość Backlogu Produktu – może się znacząco zmienić w trakcie projektu, utrudniając korzystanie z wykresu spalania.

Wykres wypalania

Wykres spalania jest odwrotnością wykresu spalania omówionego powyżej. Również tutaj oś Y pokazuje ilość pracy do wykonania. Z kolei oś X pokazuje czas ukończenia wyrażony w liczbie Sprintów lub w datach.

Jednak Scrum Master używa Wykresu Wypalenia w nieco innym celu. Dzieje się tak, ponieważ nie tylko pomaga w mierzeniu postępu produktu i postępu zespołu. Ta metryka ocenia również, jak zakres pracy w projekcie zmienia się w czasie. Dlatego dobrze sprawdza się w projektach o zmiennym zakresie.

Wykres wypalenia jest również narzędziem planowania, które z czasem staje się coraz bardziej efektywne. Daje odpowiedzi na pytanie, ile pracy według szacunków wykona Zespół Deweloperski w kolejnym Sprincie.

Skumulowany schemat przepływu

Trzecim typem diagramu, który jest bardzo owocny w pracy Scrum Mastera z Zespołem Deweloperskim, jest Diagram Przepływów Kumulacyjnych. Zawiera analizę stabilności tempa i produktywności Zespołu Deweloperskiego. Układ jego osi jest taki sam jak wykresu wypalenia, dlatego często określa się go mianem jego bardziej złożonej wersji.

Jednak skumulowany schemat przepływu nie służy wyłącznie do określenia liczby zadań wykonanych w danym okresie czasu. Uwzględnia również liczbę zadań oczekujących w kolejce na wykonanie. Dzięki temu umożliwia diagnozowanie tzw. „wąskich gardeł” – momentów procesu, które spowalniają powstawanie produktu.

Ta bardzo diagnostyczna funkcja sprawia, że ​​jest to jedna z najbardziej użytecznych metryk w rękach Scrum Mastera. Dzieje się tak, ponieważ pozwala zreorganizować pracę w taki sposób, aby inaczej rozłożyć siłę Zespołu Deweloperskiego i uniknąć przestojów.

Monitorowanie doświadczeń użytkowników przez pracowników Deweloperzy

Regularne i skrupulatne prowadzenie i analiza statystyk jest istotną częścią efektywnej pracy Scrum Mastera. Musi jednak mieć na uwadze przede wszystkim user experience developerów, czyli sposób, w jaki postrzegają pracę w Zespole Scrumowym. Jednak to nie jakość metryk decyduje, ale sposób, w jaki Scrum Master je wykorzystuje.

Jeśli statystyki są prowadzone zgodnie z zasadami Scrum – są przejrzyste, jawne i zrozumiałe dla zaangażowanych Developerów – mogą być sposobem na zmotywowanie zespołu do wydajniejszej pracy lub nagrodzenie go za świetne wyniki. Statystyki mogą jednak funkcjonować jako narzędzie do wywierania presji na Zespół Deweloperski. Wtedy ich wskazania stają się generatorem oskarżeń i resentymentów. Mogą przyczynić się do pogorszenia morale zespołu i zepsucia praktyk pracy zespołowej.

Drugim ważnym czynnikiem doświadczenia pracowników Developerów, o który musi zadbać Scrum Master pracujący z narzędziami statystycznymi, jest sposób zarządzania ich czasem. Dzieje się tak, ponieważ Scrum Master musi mieć wystarczająco dużo czasu, aby zająć się Zespołem Deweloperskim. Z tego powodu w przypadku dużego projektu warto rozważyć włączenie dodatkowej osoby do Zespołu Scrumowego. Będzie pełnił funkcję kierownika projektu i zajmie się metrykami. Dzięki temu odciąży Scrum Mastera – i do pewnego stopnia Product Ownera – od zadań, które odciągają go od pracy z Zespołem Deweloperskim.

Statystyki i metryki – podsumowanie

Scrum Master powinien na bieżąco śledzić podstawowe statystyki opisujące pracę Zespołu Deweloperskiego. Ich umiejętna interpretacja zwiększa szansę na szybkie dostrzeżenie problemów w pracy Zespołu i reagowanie na nie. Jednak ważniejsze niż utrzymywanie wykresów jest to, co robi z nimi Scrum Master. Nie powinni traktować metryk jako narzędzia do oceny Zespołu, ale raczej traktować je jako przydatną pomoc w motywowaniu Zespołu i diagnozowaniu własnego sposobu działania. Dzieje się tak, ponieważ metryki będą użytecznymi narzędziami tylko wtedy, gdy pomogą usprawnić procesy doskonalenia Zespołu i Produktu.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube.

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

1. Słowniczek podstawowych pojęć, ról i pojęć
2. Co to jest Scrum?
3. Wartości Scrum
4. Jak wdrożyć Scrum w swojej firmie?
5. Zespół Scrumowy - co to jest i jak działa?
6. Kim jest Product Owner?
7. Najczęstsze błędy Product Ownera
8. Kim jest Scrum Master?
9. Charakterystyka dobrego Scrum Mastera
10. Najczęstsze błędy Scrum Mastera
11. Jakie statystyki i metryki powinien śledzić Scrum Master?
12. Współpraca Product Ownera ze Scrum Masterem
13. Zespół Deweloperski w Scrum
14. Najczęstsze błędy programistów
15. Artefakty Scrum
16. Skalowanie Scrum
17. Backlog Sprintu
18. Czym jest Backlog Produktu?
19. Czym są historie użytkowników?
20. Tworzenie najlepszej historii użytkownika z INVEST
21. Najczęstsze błędy User Story
22. Kryteria akceptacji historii użytkownika
23. Szacowanie i punkty fabularne w Scrumie
24. Poker Planowania
25. Drużynowa gra szacowania
26. Definiowanie przyrostu
27. Wydarzenia scrumowe
28. Czym jest Sprint w Scrumie?
29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
30. Co to jest wykres spalania?
31. Jak stworzyć i zinterpretować wykres spalania?
32. Zalety i wady wykresu spalania
33. Tablice Kanban w Scrum i Scrumban
34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
35. Codzienny Scrum
36. Planowanie sprintu
37. Przegląd sprintu
38. Czym jest retrospektywa sprintu?
39. Typowe błędy podczas Retrospektywy Sprintu
40. Pielęgnacja Backlogu Produktu