Dlaczego mierzenie Velocity może nie być dobrym pomysłem
Velocity, czyli prędkość. Popularny wskaźnik, rozpowszechniony w zwinnych projektach IT. Korzystamy z niego prawie wszyscy chociaż…raczej nie powinniśmy!
Z tego artykułu dowiesz się, dlaczego obliczanie Velocity może nie być najlepszym pomysłem. Będzie też o tym, czym w takim razie zastąpić ten wskaźnik.
Czym jest Velocity w projektach IT
Najpierw kilka zdań o tym, jak ja rozumiem klasyczne Velocity. Wszystko zaczyna się od szacowania złożoności zadań w wartościach relatywnych. Najczęściej stosowane są Story Pointy (SP) z wartościami wg skali Fibonacciego: 1, 2, 3, 5, 8, 13.
Nie będę tu mocno wchodził w szczegóły takich estymacji. Ważne jest, że po zsumowaniu wycen dla pojedynczych zadań powstaje całościowa wycena złożoności sprintu. To jest na razie plan wykonania. Na przykład wszystkie zadania sumują się do 25 SP. Na koniec sprintu sumujemy SP dla zrealizowanych zadań. Powiedzmy, że z zaplanowanych 25 SP zrealizowano 20 SP. Mamy więc prędkość zespołu w danym sprincie równą 20.
Zbierając prędkości z kolejnych sprintów, powstaje średnia wartość Velocity. Coś takiego jak na poniższym wykresie.
Na tym przykładzie widać, że wartość średnia jest w okolicach 15-16 SP. Tyle więc SP powinien dostarczyć zespół w kolejnych sprintach. Oczywiście średnio, bo były jednak też sprinty na poziomie 10 SP i 20 SP.
Teoretycznie wszystko wygląda dobrze, ale...
Biznes rozumie tylko dwa wskaźniki
Jeżeli rozmawiasz z kimś z tzw. biznesu, czyli na przykład wizjonerem budowanego produktu czy członkiem zarządu, który sponsoruje projekt, to na pewno padną dwa pytania. Po pierwsze, ile to potrwa. Po drugie, ile to będzie kosztować. Ludzi biznesu nie interesuje zwykle wiele więcej.
Velocity nie odpowiada bezpośrednio na te pytania. Nie ma tam czasu ani pieniędzy. Jest jakiś tajemniczy wskaźnik, z którym nie wiadomo co zrobić. Na pytania o czas i budżet nie możesz odpowiedzieć, że “Velocity zespołu wynosi 16 SP.” Biznes od razu zacznie pytać “to ile to jest dniówek?”
Dlatego ten wykres nie nadaje się do przedstawienia biznesowi bez wcześniejszego wprowadzenia lub instrukcji obsługi. Już samo to powoduje, że użyteczność tej miary jest dość niska.
To jednak nie koniec problemów.
Velocity jak licznik w samochodzie
Powiedzmy, że po długich wyjaśnieniach biznes w końcu zrozumiał, czym jest to Velocity. Jakiego polecenia możesz się wkrótce spodziewać?
Jest spora szansa, że ktoś przyjdzie do Ciebie z pomysłem typu: “Terminy nas gonią, trzeba zwiększyć Velocity!”
Zapewniam Cię, że możesz bez problemu przyjąć takie polecenie na klatę. Bo z Velocity jest jak z licznikiem przejechanych kilometrów w samochodzie. Może kojarzysz ten dowcip, gdy klient dzwoni do handlarza samochodami z pytaniem:
- “Dzień dobry, jaki przebieg ma ten samochód?”
- “A jaki by Pan chciał mieć?”
Z Velocity jest tak samo. Skoro estymacje relatywne są dość subiektywne, to nikt nie zauważy, gdy zespół zacznie wyceniać zadania nieco wyżej niż poprzednio. W rezultacie wzrośnie liczba dostarczanych SP na sprint, przez co wzrośnie Velocity. Wszyscy będą zadowoleni! No może poza klientami, którzy dostaną mniejszy przyrost niż poprzednio, bo zespół, zamiast skupiać się na zadaniach będzie mocno zaangażowany w “walkę z systemem”.
Z tych powodów Velocity jest metryką, która nie pasuje do języka i stylu myślenia biznesu. Są jeszcze inne przeciwskazania.
Ostrożnie, bo się zepsuje!
Velocity nie jest agile, tylko fragile. Wykres ten jest użyteczny, dopóki nic się nie zmienia w strukturze zespołu i projektu. Ponieważ Velocity to suma wycen zadań dostarczonych przez każdą osobę, to zmniejszenie lub zwiększenie składu zespołu o jedną osobę unieważnia poprzednio zarejestrowane wyniki. Średnia przestaje się zgadzać. Następuje reset i trzeba zacząć mierzyć od początku. W środowiskach o wysokiej rotacji jest to więc całkowicie bezużyteczny wskaźnik.
Pewnym rozwiązaniem może być przeliczanie poprzednich wartości z proporcji lub określanie Velocity w przeliczeniu na osobę. Brzmi to jednak jak zaślepka, która jeszcze bardziej komplikuje korzystanie z Velocity.
Poza trwałymi zmianami także chwilowe wahania prędkości potrafią mocno zaburzyć obliczenia. Jeżeli zaczniesz mierzyć velocity w okresie luty - maj, to błędem byłoby zakładanie tej samej wartości w okresie czerwiec - sierpień, ze względu na okres urlopowy. Ponownie potrzebne są jakieś przeliczenia proporcjonalne lub analogia do zeszłych lat. Brzmi to jak spore wyzwanie.
Na końcu jest i tak jeden, duży problem.
Ile osób, tyle interpretacji
Nie tylko biznes ma problem z interpretacją Velocity. Także zespoły wytwarzające oprogramowanie różnie interpretują uzyskane w ten sposób wyniki. Szczególnie popularny jest pewien paradoks:
- Osoby w zespole wspólnie przyznają, że szacunki w SP są nieprecyzyjne i częściowo subiektywne. Służą szybkiej ocenie złożoności zadań. Złapaniu skali całego projektu, czy zbliżającego się wydania. Analizowanie jednak czy zadanie ma mieć 2, czy 3 SP na dłuższą metę nie ma sensu. Zwykle, w wyniku kompromisu przyjmowana jest jedna z wartości i idziemy dalej.
- Te same osoby uznają jednak, że skoro średnio dostarczane jest X SP per sprint, to w zbliżającym się sprincie można wciągnąć nie więcej zadań niż za X SP. I ani punktu więcej.
Czy to nie jest sprzeczność?
Nieprecyzyjna i uśredniona miara jest używana do planowania z chirurgiczną dokładnością.
Dlatego też prawidłowe wdrożenie Velocity wymaga pewnej wiedzy i zrozumienia tematu w całym zespole. W przeciwnym razie zaszkodzi także zespołom wytwarzającym oprogramowanie. Uwzględniając wszystkie wymienione wady, taki wysiłek może się zwyczajnie nie opłacać.
Czy jednak Velocity jest konieczne w Scrumie?
Dlaczego więc Velocity jest tak popularne. Czy mierzenie Velocity wynika może z reguł Scruma?
Nie, zdecydowanie nie! W Scrum Guide nie ma ani słowa o Velocity. Standard nie narzuca żadnych wskaźników czy sposobów mierzenia postępów.
Popularność Velocity wzięła się być może z tego, że raport ten jest od lat dostępny w Jirze.
Jako jeden z nielicznych w tym narzędziu, przez lata oferował pewną formę “mierzenia postępu”. Jest przy tym dość łatwy do uzyskania. Dlatego pewnie sporo liderów zespołów i kierowników projektów sięgnęło po taką formę raportowania.
Co w zamian?
Skoro Velocity ma tyle wad, to czym je zastąpić?
Zamiast prędkości mierzonej w SP warto poszukać wskaźników, które mówią językiem biznesu. Dobrym przykładem jest czas trwania cyklu (Cycle Time). Taki wykres pokaże, ile czasu zajmuje dostarczenie jednego zadania. Odpowiednio przygotowany pozwala dodatkowo ocenić prawdopodobieństwo ukończenia zadania o danym czasie.
Poniżej widzisz przykład takich pomiarów.
Przykładowy pomiar czasu trwania cyklu (Cycle Time). Więcej przykładów takich wykresów znajdziesz tutaj: https://it.projectmakers.pl/newsletter
Dzięki temu biznes od razu widzi, że jest 50% szans na dostarczenie zadania poniżej 10 dni i 90% szans, że będzie to szybciej niż 14 dni. Jest to już konkret, na podstawie którego można podejmować decyzje. Nie trzeba nic dodatkowo tłumaczyć.
Pochodną czasu trwania cyklu jest przepustowość (Throughput). Wskaźnik ten pokazuje, ile zadań jest dostarczanych w danym przedziale czasu (np. w trakcie jednego tygodnia). Dzięki temu biznes może odpowiednio zaplanować priorytety.
To tylko kilka przykładów. Zachęcam Cię do dalszych poszukiwań i wychodzenia poza to, co oferują narzędzia typu Jira.
