Pracując zwinnie powinniśmy opierać swoje działania, zmiany i eksperymenty o twarde dane. Nawet jeśli „wydaje nam się”, że wiemy jak coś zorganizować lepiej, to musimy to potem umieć zweryfikować. Tu nieocenione są wartości liczbowe, które jasno pokażą nam, czy mieliśmy rację, czy też się myliliśmy.
Typowe agile’owe mierniki i metryki
Typowe mierniki to oczywiście Velocity, Lead Time, a także metryki jakościowe jak liczba zgłaszanych błędów czy proporcje rozwoju do utrzymania. Product Ownerzy i Project Managerowie mierzą także wskaźniki produktowe (wartość produktu, popularność funkcjonalności, ale też jak produkt sobie radzi na rynku) i projektowe (koszty, terminy, zysk).
Niniejszy tekst jest inny niż większość na naszym blogu, bo bez lania wody przechodzimy do omawiania różnego rodzaju miar, z którymi mieliśmy okazję się spotkać. Potraktujcie to jako katalog, z którego możecie wybrać sobie to, co Wam odpowiada.
Podzieliliśmy te metryki na podstawowe, jakościowe, produktowe i inne (czytaj: niepolecane). Mamy nadzieję, że odpowiedzą one przynajmniej na część Waszych potrzeb związanych z miarami stosowanymi w zwinności.
Podstawowe mierniki zwinności
Velocity (prędkość)
Najbardziej popularna miara, wyznaczamy ją sumując oszacowanie dowiezionych, zgodnych z Definition of Done Elementów Backlogu z kilku ostatnich Sprintów i dzieląc przez liczbę Sprintów. Czyli, jeżeli w ostatnich 5 Sprintach zrealizowaliśmy wymagania za 20, 22, 18, 19, 24 Story Points to Velocity wyniesie 20,6 SP/Sprint.
Alternatywnie, jeśli wszystkie wymagania są podobnego rozmiaru to możemy po prostu liczyć ich liczbę. Jeśli zrealizowaliśmy 5, 5, 4, 5, 7 wymagań, to nasza prędkość wyniesie 5,2 wymagań/Sprint.
Zwykle Velocity to średnia krocząca i zależy nam na tym, żeby była to wartość stała, która delikatnie zwiększa się w czasie. W celu pomiaru stabilności możemy mierzyć odchylenie standardowe, przy założeniu, że Velocity jest średnią kroczącą z ostatnich n Sprintów.
Velocity mówi o prędkości realizacji (kończenia) elementów z Backlogu Poduktu. Pozwala nam prognozować kiedy zabierzemy się za które wymaganie, o ile ich kolejność nie ulegnie większym zmianom. W przypadku mierzenia Velocity, kluczowe są dwa aspekty: jego wartość i stabilność. Więcej na ten temat opisaliśmy w tekście dotyczącym Velocity.
Throughput
Wariantem Velocity jest Throughput czyli przepustowość – średnia liczba produktów dostarczonych w danym czasie. Jeśli za „produkt” uznamy zrealizowane wymaganie, a za „czas” – Sprint, to będzie to dokładnie to samo co Velocity. Throughput możemy mierzyć też dla innych wartości, jak np. liczba wgrywek (deploy’ów) robiona w Sprincie czy w miesiącu.
Cele Sprintu (Tak/Nie)
Osiągalność Celu Sprintu to miernik, który powinien być śledzony w absolutnie każdej organizacji i pokazywany w każdym zespole na osi czasu. Jest to binarny miernik Tak/Nie, który mówi o tym, czy udało się zrealizować zapis przygotowany na Planowaniu Sprintu jako Cel Sprintu. Nie interesuje nas % spełnienia – jest to rzecz, która albo się zadziała, albo nie. Jeśli cel jest spełniony w 99%, ale zabrakło np. testów czy podpisu, czy czegokolwiek innego, to nie jest on spełniony w ogóle.
Wizualizacja tego wskaźnika na przestrzeni ostatnich Sprintów mówi wiele o kondycji w zespole.
TTM – Time to Market
Time To Market (TTM) to czas od momentu rozpoczęcia prac nad daną rzeczą, aż do jej udostępnienia. Tą rzeczą może być np. nowa funkcjonalność w naszym systemie (np. Story bądź Bug) albo nawet cały produkt czy aplikacja. „Udostępnienie” oznacza moment, w którym staje się ona użyteczna – trafia do sprzedaży czy zamawiającego. TTM co do zasady obejmuje całość procesu wytwórczego i tutaj musimy zwrócić uwagę na to, jakie definicje startu i zakończenia naszego działania przyjmiemy.
Jeśli zależeć nam będzie na podaniu jak najdłuższego czasu, naszym początkiem prac będzie wczesna incepcja, kiedy to dowiadujemy się o konieczności wykonania jakiegoś zadania i zabieramy się za pierwsze prace analityczne. Możemy w ten sposób uargumentować chociażby wysokość nakładów inwestycyjnych na realizowane przedsięwzięcie.
Jeśli zależeć nam będzie na podaniu jak najkrótszego czasu, najprawdopodobniej weźmiemy pod uwagę okres od rozpoczęcia dewelopmentu, aż do jego zakończenia. Nie uwzględniając finalnych testów i samego wdrożenia będziemy jednak ponosić ryzyko związane z jakością. TTM mierzymy jako wartość średnia na przestrzeni wszystkich zgłoszeń danego typu.
Lead Time, Cycle Time
Jeśli za początek mierzenia czasu TTM przyjmiemy moment pojawienia się zgłoszenia (błędu, wymagania, etc.) w naszym systemie, a za koniec – udostępnienie go użytkownikom końcowym (wgrywka, deploy, wdrożenie, emisja) to TTM będzie tożsame z czasem nazywanym Lead Time.
Cycle Time to czas przejścia zadania przez wybrane czynności. Możemy tutaj mierzyć np. Cycle Time od zgłoszenia danego zadania do jego podjęcia (i porównywać to np. z SLA) albo mierzyć tylko i wyłącznie „czas dewelopmentu” (Development Cycle Time), które nie obejmuje on okresów oczekiwania w backlogu czy na liście To Do.
Miary związane z Epikiem
Wiele miar, które zwyczajowo przywiązuje się do wymagań bądź zespołów można też wykorzystać szerzej, w ramach Epików. W szczególności wydaje się, że Burndown i Burnup Charty oraz Cumulative Flow Diagramy przeznaczone dla Epików którymi znajduje się jeden zespół mogą dostarczyć wiele informacji na temat tego, jak realizowane są poszczególne obszary funkcjonalne.
Analogicznie, jeśli Epiki są dla nas zleceniami bądź bliżej im do Features, to możemy mierzyć np. Throughput, TTM albo Cycle Time, a także zmiany jego szacunku w czasie (np. wstępna estymata kontra suma Story Points składających się na realizację).
Metryki jakościowe
Praca Zaplanowana/Niezaplanowana
Pod tym pojęciem kryje się zestaw mierników, które możemy używać do śledzenia „sprawdzalności planowania”. Tzn. możemy mierzyć ile % pracy (wyrażonej w sztukach bądź Story Pointach czy MD), która została zaplanowana na Planowaniu Sprintu, została faktycznie ukończona. Możemy też sprawdzać to od drugiej strony – ile % pracy, które zostało oznaczone jako „Done” na koniec Sprintu faktycznie było w naszym Backlogu na koniec Planowania.
Dla przykładu – planujemy sobie 20 Story Points, w trakcie Sprintu dorzucamy 10 i koniec końców realizujemy 22, z czego 8 „nowych”. Sprawdzalność planowania wynosi 14/20 = 70% (zrealizowaliśmy tylko 14 z zaplanowanych 20 punktów). Patrząc od drugiej strony, 14/22 czyli 63% prac, które zrealizowaliśmy na koniec było faktycznie zaplanowane. Patrząc z trzeciej dodaliśmy 10/20 = 50% zakresu Sprintu (albo alternatywnie 10/30, czyli 33% rzeczy były realizowane „z boku”).
Jako, że nie ma jednego przepisu na liczenie tego współczynnika, trzeba bardzo dobrze zastanowić się „co chcemy mierzyć” i do czego tę wartość wykorzystać.
Trafność Estymacji
Jeśli zmieniamy wycenę zadań po ich realizacji (a raczej nie powinniśmy), możemy liczyć trafność estymacji na zasadzie proporcji wyceny po realizacji, do wyceny przed planowaniem. Zmiany szacunku na podstawie doświadczeń będą się działy zawsze i wynikają z samego podejścia zwinnego, nie przywiązywałbym więc większej wagi do tego współczynnika.
Proporcja Rozwoju do Błędów
Jeżeli w naszym backlogu lądują też błędy do poprawy, wynikające z naszych wcześniejszych prac, to warto śledzić proporcję wymagań do błędów, liczoną w sztukach, Story Points lub godzinach (zależy jakie mamy dane). Istotne są dwie wartości: ile planujemy do realizacji wymagań w stosunku do błędów (np. 15 Story Points wymagań i 3 Story Points błędów = 83% rozwoju) oraz ile faktycznie realizujemy na koniec Sprintu (zrealizowaliśmy 10 Story Points wymagań i 12 Story Points błędów = 45% rozwoju).
Tu warto odróżnić błędy od „zwykłych” rzeczy utrzymaniowych, jak konfiguracje i wdrożenia, które mogą mieć taki sam typ zgłoszenia np. w Jira. Trzeba to po prostu liczyć dobrze.
Miary Produktowe
Return on Investment (ROI)
„Najprostsza” miara produktowa to ROI, czyli zwrot z inwestycji. Musimy posiadać jakiś poziom (najczęściej Epik bądź cały Produkt) w ramach którego jesteśmy w stanie podsumować nasze nakłady w jakimś okresie, a następnie – po wdrożeniu – zmierzyć o ile zmieniły się nasze przychody. Stosunek zwiększonych przychodów (delty) do nakładów to właśnie nasze ROI.
Problemów z ROI jest wiele, począwszy od niejasnego związku przyczynowo-skutkowego pomiędzy realizowanymi funkcjonalnościami, a przychodem/zyskiem. Często jest to możliwe tylko na poziomie wydania, a nie poszczególnych epików czy wymagań. Przychód i zysk mogą także reagować na fluktuacje okresowe, sezonowe bądź np. akcje marketingowe i trudno jest pokazać zależność wprost.
Dostarczona Wartość
Value Points to odpowiednik Story Points, ale w ujęciu wartości dostarczanej dla naszego odbiorcy. To znaczy, że porównując wymagania między sobą określamy „na czym naszemu klientowi bardziej zależy” bądź „z czego będzie bardziej zadowolony”. Podobnie jak wspomniane oszacowanie, tak i Value Points są miarą względną. To znaczy, że w odróżnieniu od ROI nie staramy się określić „ile skorzystamy na tym wymaganiu”, tylko „jak się ma wartość poszczególnych wymagań w stosunku do siebie”.
Jeżeli już wprowadzamy miarę punktową wartości, to zwykle korzystamy z dobrze znanego zbioru opartego o ciąg Fibonacciego. To ciąg 1, 2, 3, 5, 8, 13, 21, 34, 55, itd. Pamiętamy przy tym, że te wartości mają znaczenie jedynie w przypadku porównywania między sobą wymagań dotyczących jednego produktu. Na pewno nie próbujemy przeliczać ich na żadną twardą walutę. Równie dobrze możemy skorzystać z innych miar względnych, jak na przykład rozmiaru koszulek (S, M, L, XL) bądź innej skali względnej – 1, 10, 20, 50, 100, 200, 500, 1000.
Jesteśmy w stanie mierzyć sumę wartości, jaką zespół dostarcza w czasie, pamiętając, że mimo wszystko jest to miara symboliczna i pokazuje nam czy w danym okresie skupiamy się bardziej na wartości, czy np. na prędkości.
NPS
Net Promoter Score – metryka odpowiadająca na pytanie jak bardzo nasi klienci poleciliby nasz produkt innym. NPS jest całkiem dobrze opisanym i ustandaryzowanym sposobem na mierzenie lojalności i jakości naszych produktów, ale nie odpowiada on na poszczególne aspekty naszego produktu, tylko patrzy całościowo.
Objective & Key Results (OKR-y)
OKR-y to język mówienia o celach, który ułatwia współpracę zespołów i pomaga rozwiązywać problemy związane z realizacją strategii. Najczęściej OKR-y występują jako element strategii, definiowane są kwartalnie i/lub rocznie, a następne dekompowane są na działy, zespoły bądź produkty. Na podstawie OKR-ów budowane są cele niższego rzędu – jako OKR-y, Cele Produktów, Cele Sprintów czy nawet KPI.
Key Results („Kluczowe Rezultaty”) to 3-5 konkretnych, mierzalnych punktów, które spełnione potwierdzą nam, że osiągnęliśmy cel. Są to mierzalne wskaźniki pokazujące stopień realizacji poszczególnych celów. Mogą służyć np. jako wartości pośrednie, pokazujące stopień realizacji Kluczowych Rezultatów, ale już same KR-y powinny być dla nas mierzalnym wyznacznikiem. KR-y mająbyć ambitne i mówi się, że powinniśmy być zadowoleni z realizacji KR-ów w 70%.
KR-y mogą być jakościowe („co najmniej x”) bądź binarne („albo się zadzieje, albo nie”) i bardzo często są ze sobą sprzeczne, np. liczba obsłużonych klientów większa niż x, ale średnia ocena co najmniej y. To razem powoduje, że nasz produkt ma spełniać pewne warunki i dostarczać jakąś jakość.
Ponieważ KR-y muszą być mierzalne, same w sobie są dla nas miernikiem wartości produktu i zwykle nie wymagają nawet adaptacji.
KPI
Prawo Goodharta mówi, że „Każda obserwowana statystycznie zależność ma skłonność do zawodzenia, w momencie w którym zaczyna być wykorzystywana do celów regulacyjnych”. Próba wykorzystania KPI do oceny bądź mierzenia sposobu pracy zespołu, musi uwzględniać tę prawidłowość (KPI bardzo szybko i bezwiednie staną się celem samym w sobie). Dlatego też najlepiej opierać KPI o rezultaty biznesowe osiągane na podstawie wyników prac strumieni wartości. Np. „liczba nowych aktywnych klientów” – nawet jeśli zespół zrealizuje to w sposób „niestandardowy”, to i tak będzie to biznesowo pożądane.
Mówiąc inaczej, jeżeli mamy np. Epiki opisane w formacie User Stories (Jako… Chcę… Aby…), to naturalnym kandydatem na KPI mierzący efektywność produktu jest część „Aby”. Jeżeli mamy „Aby ułatwić i przyspieszyć proces składania wniosku”, to naturalne KPI to liczba błędnych wniosków (oczekiwany spadek), czas składania wniosku (mierzony od otwarcia formularza, do kliknięcia 'zapisz’, oczekiwany spadek) oraz ogólna liczba wniosków (zakładamy utrzymanie poprzedniego trendu) i liczba porzuconych wniosków (oczekiwany spadek).
Czasami możemy takie „Aby…” przekuć na KPI także z wymagań niższego poziomu (Features, Stories).
Podejście mierników per Epik bardzo często wymaga dodatkowej pracy – obudowania naszej aplikacji czujkami pozwalającymi na mierzenie tych rzeczy. Jest to jednak nakład, który w przyszłości pozwala mierzyć stan naszej aplikacji/rozwiązania nie tylko u siebie „na testach”, ale też często na produkcji. Pozwoli też zauważyć, że nasze rozwiązania zmierzają w złą stronę.
Źródłem KPI-ów mogą być dla nas także poszczególne Cele Produktu, w oparciu o które możemy zbudować metryki i mierniki pokazujące, że Cel został osiągnięty.
Testy A/B
Jeśli zespoły posiadają takie możliwości to bardzo często realizując jakieś wymaganie jesteśmy w stanie zrobić je na dwa (bądź kilka) sposobów. Często nie zwiększa to kosztu rozwiązania, więc zamiast debatować nad tym, czy ścieżka A czy B jest bardziej wartościowa, można wydewelopować obie, a następnie zweryfikować u klientów testami A/B – część widzi jedne rozwiązanie, a część drugie, a następnie porównujemy wyniki/mierniki z obu różnych źródeł.
Tutaj należy pamiętać, że zbyt wiele testów A/B na raz zaciemnia ewentualne wnioski.
Inne Miary (niepolecane)
Liczba linijek kodu/Sprint, Liczba zgłoszonych bugów/developera/Sprint albo Liczba zgłoszonych bugów/zespół/Sprint – nic nam nie mówią, tylko szkodzą.
Liczba zgłoszonych bugów po wydaniu wersji aplikacji jest ciekawym miernikiem jakościowym, który mówi nam tylko o tym „jak było” i może warto go śledzić, ale mówi on za mało, żeby był przydatny. Trudno jest po prostu go do czegoś wykorzystać.
Liczba wymagań zwróconych przez klienta do poprawki/dorobienia jest podobnym miernikiem, który mówi nam ile razy coś co jest „done” wraca na warsztat i psuje nam Velocity i jakość. Możemy to mierzyć liczbowo bądź procentowo.
Jak w kontekście informacji: „na każde 8 godzin spędzonych w pracy przypada 2 godziny i 53 minuty pracy faktycznej” powinien negocjować stawkę godzinową programista pracujący zdalnie?