W swojej kultowej powieści „Diuna” Frank Herbert pisał:
Wdrap się na górę tylko tyle, by sprawdzić, że jest górą. Nie zobaczysz góry z jej szczytu.
Mówiąc mniej poetycko – nasze cele są ważne, ale droga do ich osiągnięcia również. Czasami może się okazać nawet bardziej istotna od punktu docelowego.
Zespoły wciąż się zmieniają, czasem na lepsze, czasem – niestety – na gorsze. Z czego wynika spadek wydajności zespołów i jak uchronić się przed jego skutkami? W jaki sposób odnaleźć te elementy, które są przewagą, atutami danego zespołu i jak je wzmocnić? Tutaj z pomocą przychodzą nam metryki. Ale metryki używane mądrze – nie jako narzędzie do wywierania presji na zespół czy oceniania go, ale jako sposób na szybkie zauważanie problemów i reagowanie na nie. Jest to szczególnie ważne, jeśli chcemy, aby zespół wciąż się rozwijał i dążył do samodoskonalenia.
Na początek należy zdać sobie sprawę, że metryki nie są sobie równe. Możemy je podzielić na dwa typy: metryki mierzące postęp prac nad produktem oraz metryki mierzące rozwój i zwinność zespołów. Metryki produktowe, skupiające się na śledzeniu rozwoju produktu, mogą pomóc w analizowaniu czy tworzony produkt jest odpowiednio dostosowany do potrzeb rynku. Natomiast metryki skupione na analizie zespołu, śledzące postępy w jego rozwoju, pomagają w lepszym zrozumieniu procesu dostarczania przyrostu i optymalizacji wydajności zespołu.
Oba typy mają na siebie wzajemny wpływ i fluktuacje w zakresie pomiaru zespołu mają wpływ na wytwarzany produkt. Podobnie jak zmiany w zakresie płynności dostarczania przyrostu, nigdy nie pozostaną bez wpływu na zespół.
Dziś krótko o jednych z najbardziej znanych metryk i typów wykresów stosowanych w Scrum – wykresach spalania.
Burn-down chart
Jest to metryka, która śledzi postęp prac na produktem, ale w mojej ocenie jest najbardziej przydatna w kontekście pomiaru postępu zespołu, ponieważ pokazuje jak szybko w trakcie pracy nad produktem Zespół Deweloperski kończy pracę nad User Stories (US) lub nad zadaniami (w zależności od przyjętego przez zespół sposobu estymacji pracy). Na osi Y wykresu zaznaczana jest ilość pracy (mierzona np. w Story Point lub zadaniach), zaś na osi X przedstawiany jest czas w odniesieniu do projektu.
Każdy projekt musi mieć arbitralnie ustanowiony początek, często określany jest także jego koniec oraz tzw. milestony. Projekty z nieokreślonym czasem zakończenia występują niezwykle rzadko, dlatego burn-down chart jest świetnym narzędziem do śledzenia postępów i możliwości dostarczenia produktu w skończonym czasie. W odniesieniu do Sprintów wykres spalania obrazuje kilka rzeczy:
- Ile pracy zostało wykonane do tej pory, czyli ile Story Point’ów (SP) mamy zakończone.
- Ile pracy powinniśmy jeszcze wykonać?
- Kiedy prawdopodobnie uda się zakończyć prace nad produktem?
Idealny burn-down chart jest linią prostą, spadającą od lewej do prawej strony w kierunku 0 dla osi Y (funkcja monotoniczna malejąca). Niestety w praktyce sytuacja idealna, czyli wykres stale malejący, jest trudna do osiągnięcia. Wpływ na to mają m. in.: zmienna prędkość pracy zespołu, a także fluktuacje zakresu.
Najistotniejszą kwestią jest wykorzystanie burn-down chart jako narzędzia do podparcia dyskusji na temat możliwych usprawnień i dostosowania pracy do wciąż zmieniających się wymagań i uwarunkowań. Wykres prowadzony w granulacji Sprintów, gdzie jednostką czasu jest pojedynczy Sprint, pozwala na śledzenie tendencji zmian zachodzących w zakresie prac nad produktem. Z kolei wykres prowadzony dla pojedynczych Sprintów, gdzie jednostką czasu jest dzień, pozwala na śledzenie prac zespołu.
Powyżej zamieszczony przykład wykresu burn-down chart możemy przeanalizować. Łatwo zaobserwować, że w dwóch pierwszych Sprintach, zespół wykonał mniej pracy niż zakładał, po czym w Sprincie 3. wyprzedził nieznacznie harmonogram (ilość zrealizowanych Story Point znajduje się poniżej linii prognozy teoretycznej). Wykres niestety nie dostarcza nam informacji co mogło się wydarzyć w Sprincie 4., gdzie (teoretycznie) nie zrealizowano żadnego Story Point’a. Różnica rzeczywistych Story Point’ów między Sprintem 4 a 5 wynosi 0.
Jestem zwolenniczką prowadzenia burn-down chart dla pojedynczych Sprintów, aby Zespół Deweloperski mógł dzień po dniu (np. w trakcie Daily) śledzić swoje postępy. Pozwala to na zauważenie, na możliwie wczesnym etapie prac, sytuacji, w której Cel Sprintu zaczyna być zagrożony. Praca deweloperska wymaga czasu, to oczywiste, zatem wypracowane Story Point’y rzadko pojawiają się na wykresie już pierwszego dnia. Jednak, jeśli Definition of Done (DoD) dla User Stories jest spełniana wyłącznie pod koniec Sprintu i staje się to tendencją, to jest ewidentnie obszar, który wymaga ulepszenia.
Rolą Scrum Mastera jest zauważanie tego trendu, możliwych zagrożeń z niego wynikających i wsparcie Zespołu w ich usunięciu. Wizualizacja postępu pracy pozwala na szybkie i łatwe zauważenie sytuacji, w której Sprint Backlog nie zostanie przełożony na przyrostu lub gdy Cel Sprintu jest zagrożony. Możliwość dostosowania się do konkretnych realiów jest możliwa jedynie wtedy, kiedy zdajemy sobie sprawę z występowania niedogodności lub problemów.
Czasami nie uda się zapobiec sytuacji, w której zakres Sprint Backlogu nie zostanie zrealizowany, mimo dostrzeżenia tych zagrożeń. Niemniej dużo lepszą sytuacją jest jedno ukończone w pełni User Stories z np. trzech zaplanowanych niż trzy US w trakcie prac i zerowy przyrost na koniec Sprintu.
Powyżej znajduje się wykres burn-down dla pojedynczego Sprintu – 4. z wykresu całego projektu. Sprint ten był nietypowy, ponieważ – w teorii – zespół nie ukończył żadnego Story Point. Bardziej szczegółowa analiza pozwala na lepsze zrozumienie, co się wydarzyło w trakcie rzeczonej iteracji.
Z początku zespół nie wytwarzał przyrostu, jednak pod koniec 5. dnia Sprintu wyprzedził własne założenia, co przełożyło się na dorzucenie nowych zadań do Sprintu (zmiana scope’u). Przyczyny mogą być różne. Jedną z nich może być dobranie przez zespół zbyt wielu zadań z Product Backlogu, ze względu na dobry timing i w efekcie nie ukończenie pracy. Z drugiej strony – również ze względu na dobre tempo pracy zespołu – mogły pojawić się tzw. „wrzutki”, czyli dodatkowe zadania narzucone na deweloperów, które nie były brane pod uwagę podczas Planowania.
Warto zwrócić uwagę na to, co zadziało się między 3 a 6 dniem Sprintu, kiedy nastąpił gwałtowny spadek Story Point. Czy zespół faktycznie przyśpieszył czy ze względu na zmieniające się uwarunkowania biznesowe zrezygnowano z części scope’u?
Niezależnie od przyczyny, rolą Scrum Mastera jest każdorazowe reagowanie na te sytuacje, czy to poprzez uniemożliwienie dodawania nowych zadań przez osoby zewnętrzne czy poprzez pracę z zespołem nad wybraniem najbardziej optymalnej ścieżki wykorzystania zyskanej przewagi.
Może czas, który deweloperzy zyskali warto poświęcić na likwidację części długu technologicznego lub refaktoryzację? A może warto dobrać z Backlogu Produktu dodatkowe zadanie? Decyzja należy oczywiście od zespołu, jednak Scrum Master musi mieć pewność, że deweloperzy oraz Product Owner są świadomi konsekwencji podjętych działań a zespół będzie w stanie wytworzyć skończony przyrost (spełniający DoD).
Wykres szczegółowy dla Sprintu 4. może wyglądać nieco inaczej. Poniżej inny przykład wykresu dla tego Sprintu, skutkujący taką samą adnotacją na wykresie produktu:
W tym wypadku w dalszym ciągu ilość Story Point, z którą zespół zaczynał Sprint nie zmniejszyła się, jednak przebieg prac w Sprincie jest inny niż w poprzednim przykładzie. Jak widzimy, już na początku Sprintu zespół wytwarzał przyrost, później jednak nie był w stanie osiągnąć ani zakładanego tempa prac, ani nie zbliżył się do prognozy teoretycznej. Po 5. dniu (czyli w połowie Sprintu) ilość Story Point’ów zaczęła wzrastać.
Przyczyną tego stanu rzeczy mogły być problemy omówione dla poprzedniego przykładu, czyli „wrzutki” lub zmian scope, ale również reestymacja zadań. Zespół widząc postęp i jakość pracy zmieniają sposób estymacji zadań, a w trakcie Retrospektywy, w celu wytworzenia produktu o jak najlepszej jakości, może dodatkowo wprowadzić modyfikacje w obszarze Definition of Done. Ta teoria jest realna, jeśli spojrzymy, jak układała się praca w przeciągu następnych czterech iteracji (Sprinty 5-9). Story Pointy były sukcesywnie „spalane”, aż do osiągnięcia zakładanego zakresu na koniec 9. cyklu.
Osobiście polecam technikę estymowania każdego zadania, które zespół wykonuje w trakcie iteracji (niezależnie czy jest to zadanie zaplanowane czy „wrzutki”) oraz zaznaczania na wykresach krótkich opisów, z czego wynikają poszczególne fluktuacje. Czy zabrakło kilku lub jednej osób w zespole? Pojawiły się dodatkowe zadania? A może zmieniono kierunek biznesowy i była konieczność zmiany zakresu? Przykład stosowania tego typu opisu zaprezentowano poniżej:
Pamiętajmy, że każda metryka jest prowadzona nie tylko w celu wizualizacji postępu i przewidywania czasu, ale również może dać wiele informacji na temat tego, jak wspomóc zespół, gdzie pojawiają się największe problemy, a w których obszarach zespół odnosi największe sukcesy. Jest także wspaniałym wkładem na Retrospektywę, gdzie mając realne dane dotyczące pracy zespołu możemy popracować nad ulepszeniami.
Burn-down chart jest bardzo przydatną metryką nie tylko dlatego, że pozwala śledzić postępy zespołu, ale również w łatwy sposób pozwala generować inne przydatne miary jak Capacity oraz Velocity (więcej informacji tutaj: https://sii.pl/blog/przystepny-slownik-pojec-agile/).
Burn-up chart
Typ metryki pozwalający zarówno na pomiar postępu prac nad produktem jak i postępów zespołu. Osobiście skłaniałabym się bardziej do grupy metryk produktowych, co wyjaśnię poniżej.
Konstrukcja samego wykresu jest podobna: na osi Y zaznaczamy zakres w przyjętej skali (np. w Story Point lub zadaniach), zaś na osi X czas (np. w Sprintach lub datach).
Zasadnicza różnica między bliźniaczym wykresem burn-down chart, jest taka, że na burn-up chart zaznaczamy zmianę zakresu, a predykcję ukończenia prac nanosimy na wykres wykorzystując dane o velocity zespołu. Można oczywiście przyjąć inną formę, jednak biorąc pod uwagę zmienność velocity, ta metoda daje najbardziej realny obraz sytuacji. W poniższym przykładzie prace powinny zostać zakończone w 8. Sprincie (o ile nie zwiększy się zakres).
Na powyższym wykresie dodatkowo zaznaczono prędkość zespołu w danym sprincie (V) oraz różnicę, między założonym a ukończonym zakresem (Δ). Tak jak w przypadku burn-up chart, zachęcam do nanoszenia na wykres wszelkich danych, które pomogą w jego interpretacji. Pozwoli to określić realny termin ukończenia produktu oraz będzie stanowiło swoistą dokumentację pracy i samodoskonalenia zespołu.
Świadomość o obszarach dotyczących zalet i wad, stanowi nieocenione źródło informacji o zespołach zwinnych. Pomaga im nie tylko dążyć do ulepszania procesów, ale także wspiera umacnianie mocnych stron i pełne wykorzystanie potencjału zespołu.
Wykres burn-up dostarcza bardzo wielu danych, nawet bez szczegółowej analizy:
- Jak zmienia się zakres prac przewidzianych w projekcie?
- Ile pracy wykonano do tej pory?
- Kiedy możliwe jest ukończenie prac nad projektem?
- Ile pracy szacunkowo wykonamy w następnym Sprincie?
Informacje jakie zawiera, są przydatne zarówno z punktu widzenia Product Owner’a, jak również Zespołu Deweloperskiego. Zespół ma zwizualizowane tempo w jakim pracuje, łatwo może również określić, w którym punkcie rozwoju produktu się znajduje, co nie pozostanie bez wpływu na dalsze planowanie prac. Z kolei Product Owner widzi, w jaki sposób zmiana kierunku lub wizji biznesowej wpływa na termin zakończenia prac.
Wgląd w ten wykres pozwala również na lepsze zrozumienie zespołu, czym jest tempo jego pracy i jak istotne jest utrzymanie stałego zakresu prac przy niezmiennych terminach wykonania produktu. Z tego względu bardziej skłaniam się ku klasyfikacji burn-up chart jako metryki produktowej, która najwięcej informacji dostarcza Product Owner’owi, poprzez zbieranie danych przydatnych w podejmowaniu decyzji.
Epic burn-down
Ostatnim omawianym rodzajem wykresu spalania jest epic burn-down chart – metryka stricte produktowa. O ile wykres burn-down chart obrazuje pracę w ujęciu Sprintu, o tyle epic burn-down chart skupia się na śledzeniu postępów prac w większej granulacji – całych epików. Jest bardzo ciekawą metryką, ponieważ bierze pod uwagę wizję biznesową w konfrontacji z harmonogramem.
Obrazuje zarówno czas jaki pochłonęło zakończenie pracy nad poszczególnymi epikami, jak również fluktuacje zakresu. Śledzenie postępów sprintów jak i epików daje pełny obraz prac Zespołu Deweloperskiego oraz Product Owner’a i pozawala na łatwiejsze i trafniejsze wychwytywanie zagrożeń i problemów.
Na wykresie na osi Y pokazany jest zakres – w Story Point’ach (lub innej przyjętej skali), natomiast na osi X czas w ujęciu sprintów. Po każdym Sprincie na wykresie zaznaczane są następujące elementy:
- Ilość Story Point, które pozostały do ukończenia.
- Ilość Story Point, które zostały zakończone.
- Ilość dodanych Story Point (rozszerzenie zakresu).
Predykcje ukończenia danego epic’a można wyliczyć na podstawie danych z ostatnich 3 Sprintów. Jest to wartość Velocity zespołu dla danego epika, nie dla Sprintu (zakładając oczywiście całkowite zaangażowanie zespołu w realizacje danego epika). Dla powyższego wykresu w ciągu iteracji 2-4 zespół zrealizował 30 Story Point (SP), zakres prac również wzrósł o 30 SP.
Prognozę zawsze opieramy o aktualnie posiadane dane. Oznacza to, że obliczamy, ile cykli zajmie praca nad aktualnym zakresem (przy założeniu, że zakres nie wzrośnie). W powyższym przypadku: 60 SP przy tempie prac średnio 10 SP per Sprint (30 SP/ 3 Sprinty = 10 SP). W teorii, jeśli Zespół utrzyma tempo pracy, powinien ukończyć epik na koniec 10 Sprintu. Jest to jednak niebezpieczne założenie, ponieważ zakres ulegał znacznym zmianom. Ponadto, zespół nie posiada żadnego buforu czasowego na ewentualne fluktuacje scope’u i nie jest to jedyny epik, nad którym pracuje.
Jak widać powyżej epic burn-down chart jest wykresem słupkowym, gdzie jeden słupek odpowiada jednemu epikowi. W zależności od ilości epików, jaką mamy do zrealizowania, musimy zdecydować czy będziemy przedstawiać je na jednym wykresie czy na wielu. Pokazanie na wykresie zmian dla więcej niż 3 epików sprawi, że stanie się nieczytelny, łatwo w takim przypadku o pomyłkę. Sposób prowadzenia epic burn down chart’ów powinien być indywidualnie wypracowany przez Zespół Scrumowy, aby jego użytkowanie było maksymalnie proste i zrozumiałe dla wszystkich osób. Przykład tego wykresu z wizualizacją 3 epików przedstawiono poniżej:
Analiza wykresu epic burn-down jest szczególnie przydatna dla Product Owner’a. W powyższym przykładzie zespół ma szansę ukończyć epik 1. (E1) w 7. Sprincie. Mając czas 10 Sprintów przy założeniu, że zakres nie będzie się zwiększał, jest to dosyć bezpieczna estymata. Sytuacja jest bardziej skomplikowana dla pozostałych epików – E2 oraz E3. Epik 2. najczęściej ulegał zmianom, ale zespół też realizował najwięcej Story Point’ów w ramach prac nad nim.
Może to oznaczać, że ten epik ma dużą wartość biznesową i jest istotny z punktu widzenia interesariuszy i użytkowników końcowych. Z drugiej strony może skupiać się na istotnych elementach podstaw produktu, zatem zespół kładzie duży nacisk na jego realizację. Z kolei dla E3 w przeciągu 4 iteracji nie został wytworzony żaden przyrost. Może to wskazywać na niską wartość biznesową zakresu danego epika. A może ten epik zawiera pomysły, które będą mogły być wdrożone po wykonaniu innych zadań? Zarówno stagnacja jak i nadmierna fluktuacja są sygnałem o pojawieniu się możliwych problemów.
Zmiany zakresu oraz ilość ukończonych Story Point’ów, dla danego epika, są istotną informacją dla Product Owner’a, szczególnie podczas pracy nad Backlogiem Produktu. Obrazują, gdzie mogą pojawić się funkcjonalności, które nie są istotne z punktu widzenia klienta (brak zmian), a które zadania wymagają uszczegółowienia wizji biznesowej (mocne wahania zakresu).
Wykres prowadzony w granulacji epików pozwala na spojrzenie wysokopoziomowe na projekt. Pomaga także w zauważeniu postępu zespołu w kwestii realizacji produktu w następujących po sobie Sprint’ach. Czy wzrost zakresu jest proporcjonalny w stosunku do ilości zakończonych prac, a także jak często następuje zmiana zakresu, w tym dodawanie nowych epików. Chroniczne zmiany zakresu prac mogą wskazywać na kłopoty po stronie Product Owner’a, co powinno być sygnałem dla Scrum Master’a, że pojawił się obszar, który należy usprawnić.
Czy musimy stosować wszystkie te wykresy?
Absolutnie nie! Szczerze odradzam stosowanie wszystkich możliwych typów metryk jakie omówiono powyżej. Metrykę należy dobrać zarówno do zespołu, jak i projektu. W projektach, dla których zakres prac jest stały, bardzo dobrze sprawdzi się burn-down chart. Z kolei dla tych, gdzie scope ulega ciągłym zmianom warto stosować też burn-up chart. Jeśli natomiast pracujemy z wykorzystaniem epików wykres epic burn down chart będzie bardzo dobrym narzędziem do pracy dla Product Owner’a.
Przy wyborze odpowiedniej metody śledzenia postępu projektu, jak i pracy, istotne jest zwrócenie uwagi na najpilniejsze potrzeby zespołu. Metryki spełnią swoje zadanie tylko wtedy, kiedy pozwolą na doskonalenie procesów, produktu, jak również samego zespołu i organizacji. Stosując zbyt dużą ilość metryk nie będziemy w stanie czerpać z nich korzyści, czyli skupiać się na ciągłym usprawnianiu, ponieważ ograniczenie Retrospektywy wyłącznie do przeglądu i omawiania metryk całkowicie pozbawi to spotkanie sensu. Zmieni je w sesję raportowania, nie pozostawiając przestrzeni na pracę zespołu nad usprawnieniami, które – o ironio! – zostały zauważone w metrykach.
Wykorzystujmy metryki jako ułatwienie w codziennej pracy, narzędzie wspomagające nas w wizualizacji postępu i procesu, a także w wykrywaniu nieprawidłowości i możliwych problemów. Metryki są detektorem, narzędziem analitycznym, a także punktem wyjścia do rozmowy z zespołem. Bo to właśnie bliska współpraca ludzi należących do zespołu daje najlepsze rezultaty. Tak – to na pewno zostało kiedyś zmierzone 🙂
Zostaw komentarz