Na temat velocity opublikowałem już kilka artykułów i w żadnym z nich nie byłem przychylny idei wykorzystywania tej miary do sporządzania prognoz potencjalnych dat ukończenia prac nad rzeczami oczekującymi na realizację. Przy czym ta moja niechęć nie jest spowodowana wadami velocity (o nich kilka zdań nieco później), ale istnieniem lepszej i prostszej w użyciu miary, jaką jest przepustowość (ang. throughput).

Prędkość jako miara

Velocity jest miarą tempa przetwarzania listy rzeczy do zrobienia, a dokładnie przesuwania się po niej w dół na skutek tego, że kolejne elementy są realizowane i praca nad nimi się kończy. Wyliczana jest jako suma wycen tych rzeczy, które udało się zrealizować w wybranej jednostce czasu, np. w trakcie miesiąca. Wartość miary podawana jest zawsze w takich samych jednostkach jak wyceny, na podstawie których jest wyliczana.

Z definicji tej wynika kilka wniosków.

Po pierwsze, żeby dało się wyliczyć prędkość tak rozumianą, każda rzecz, która została zrealizowana, musi zostać wyceniona. Nie ma przy tym znaczenia, czy odbędzie się to przed rozpoczęciem prac, w ich trakcie, czy dopiero po zakończeniu realizacji.

Po drugie, wszystkie wyceny wyrażone muszą być w takiej formie, by dało się je sumować ze sobą. W praktyce oznacza to, że trzeba posługiwać się jedną skalą szacowania i musi ona być numeryczna, albo jednoznacznie przekładać się na wartości numeryczne. Stąd być może bierze się błędne przekonanie wielu użytkowników metod zwinnych, że relatywne oszacowania w story pointach i wyliczanie na ich podstawie prędkości jest pożądane albo wręcz obowiązkowe.

Po trzecie, velocity nie może być traktowane jako ekwiwalent lub choćby przybliżenie żadnej z miar wymienionych poniżej:

  • dostarczonej wartości (bo można z dużą prędkością tworzyć rzeczy zbędne lub wręcz generujące straty),
  • produktywności (bo na prędkość składają się wyceny, które mogą być całkowicie nieadekwatne, czyli zawyżone lub zaniżone),
  • zdolności do szybkiej realizacji rzeczy do zrobienia (bo przy wyliczaniu nie jest uwzględniany czas pracy nad poszczególnymi elementami, a jedynie ich wyceny),
  • nakładu pracy lub pracowitości (bo wyceny, które składają się na wyliczoną prędkość, mogą nie odzwierciedlać faktycznego wysiłku, jakiego wymagała realizacja i w ogóle nie biorą pod uwagę sposobu wykonywania pracy ani jej organizacji),
  • skuteczności rozumianej jako zdolność wytwarzania właściwych rzeczy na moment, w którym są one potrzebne (bo prędkość wyliczana jest z pominięciem oceny adekwatności, przydatności, jakości, terminowości oraz wartości tego, co zostało zrealizowane).

Po czwarte, ze względu na wyliczenie velocity jako sumy wycen rzeczy zrealizowanych w jednostce czasu, uzyskana wartość jest zawsze obciążona błędem będącym sumą błędów szacowania. Inaczej mówiąc, nie istnieje coś takiego jak w pełni obiektywna precyzyjnie wyliczona prędkość.

Po piąte: nie da się ustalić poziomu błędu, z jakim obliczana jest wartość velocity, ponieważ to wymagałoby umiejętności ustalenie poziomu błędu dla poszczególnych wycen składających się na sumaryczną prędkość. W niczym nie pomoże tu uaktualnianie tych wycen już po zakończeniu pracy, ponieważ staną się one dzięki temu nieco precyzyjniejsze, ale nigdy nie będą dokładne. A gdyby czysto hipotetycznie przyjąć, że jakimś cudem uda się takie dokładne wyceny ustalić, konieczne będzie ich skwantyfikowanie do numerycznych wartości, które da się zsumować celem wyliczenia prędkości – kosztem utraty początkowej precyzji (no, chyba że Zespół posługuje się całym zakresem liczb rzeczywistych, ale to implikuje ogromne problemy z nieskończenie rozbudowaną skalą szacowania i jest czystą abstrakcją).

Po szóste: wartością velocity bardzo łatwo manipulować lub dokonać jej nieświadomego przekłamania. Wystarczy zawyżyć lub zaniżyć wyceny, na podstawie których jest wyrażana.

Po siódme, ze względu na to, że velocity tak bardzo zależy od wycen i sposobu ich sporządzania, porównywanie jej aktualnej wartości z tą uzyskiwaną w przeszłości, albo analizy trendów zmian, mają ograniczony sens. W szczególności niewielka zmienność prędkości w dłuższym okresie nie musi oznaczać, że proces jest stabilny, jej wzrost nie musi być wynikiem udoskonaleń, spadek nie musi zdradzać pojawienia się problemów.

Po ósme, przy wyliczeniu velocity uwzględniane są wyceny tych rzeczy, nad którymi praca zakończyła się w trakcie rozważanego okresu (tego, dla którego prędkość jest ustalana). Nie oznacza to, że ich realizacja rozpoczęła się w tym okresie. Przykładowo, prędkość osiągnięta w styczniu może uwzględniać coś, nad czym prace ciągnęły się przez wiele miesięcy i dopiero w styczniu udało się je jakość zakończyć.

Po dziewiąte, skoro velocity jest miarą tempa, z jakim realizowane są elementy z listy rzeczy do zrobienia, uwzględniane w niej powinny być tylko rzeczy faktycznie ukończone w okresie, dla którego prędkość jest wyliczana. Inaczej mówiąc, jeśli prace nad czymś trwały w tym czasie, ale nie zostały jeszcze ukończone, to mimo że obiektywnie konsumowały możliwości zaangażowanych w to ludzi, materiały, środki itd., nie zostaną uwzględnione w żaden sposób w velocity. Oznacza to, że prędkość powinna być zerowa w sytuacji, gdy pomimo intensywnej pracy dużej grupy ludzi nic nie udało się ukończyć.

I po dziesiąte, velocity nie jest przypadkowo wybranym terminem. Prędkość to szybkość przemieszczania się w określonym kierunku – czyli w tym przypadku w dół listy rzeczy do zrobienia. Kreatywna księgowość polegająca na sztucznym dzieleniu pracy na kawałki tylko po to, by uzyskać wyższe velocity, jest samooszukiwaniem się przez Zespół. Owszem, coś niby udaje się „skończyć”, ale lista rzeczy do zrobienia się nie skraca, bo pojawiają się na niej nowe elementy opisujące to, co pozostało wciąż niezrealizowane.

Same wady?!

Wskazałem na szereg potencjalnych trudności z wykorzystaniem velocity, ale żadnej z nich nie traktuję jako wadę. Są one raczej ograniczeniami, które ma każde narzędzie. Velocity, o ile da się go wyliczać bez celowego dostosowania procesu i sposobu pracy tylko po to, by dało się prędkość mierzyć, może być przydatne dla Zespołów.

Analiza zmian prędkości w nieodległej przeszłości pozwala czasami zidentyfikować obszary wymagające usprawnień. Tak, wcześniej pisałem, że to ma ograniczony sens, ale wszystko zależy od tego, kto, kiedy i jakie dane analizuje. Jeśli robi to Zespół, który potrafi połączyć wizualizację zmian velocity z różnymi decyzjami, jakie podejmował i ze sposobem swojej pracy, wtedy wnioski mogą być całkiem użyteczne. Gdyby natomiast zajął się tym ktoś spoza Zespołu albo gdyby analiza objęła wiele miesięcy, które wszyscy w Zespole pamiętają już jak przez mgłę, jej wynik będzie co najmniej wątpliwy.

Informacja o średniej prędkości lub przedziale, w jakim zwykle się mieściła w ostatnich tygodniach albo co najwyżej miesiącach, może być użyta do sporządzenia prognoz dat realizacji poszczególnych elementów na liście rzeczy do zrobienia.

Prognozy dat realizacji z użyciem velocity

Prędkość to miara tempa przesuwania się w dół listy rzeczy do zrobienia. Jeśli ta prędkość się utrzyma, da się na jej podstawie przewidywać z mniejszą lub większą dokładnością, kiedy zrealizowane zostaną kolejne elementy z tej listy. Im dalej w przyszłość będą wybiegać tego typu prognozy, tym mniej trafne się okażą.

Ten sposób prognozowania jest bardzo często wykorzystywany przez Zespoły zwinne (np. pracujące w Scrumie) i nierzadko to właśnie ze względu na konieczność wyliczenia velocity, sięgają one po techniki szacowania dostarczające wycen w formie numerycznej (np. klasyczną formę Planning Pokera ze skalą wyrażoną w story pointach).

Sposób sporządzania prognozy wydaje się prosty. Wystarczy ustalić średnią wartość velocity, a następnie przejść przez listę rzeczy do zrobienia, sumując ich wyceny. Przykładowo, jeśli średnia prędkość Zespołu na miesiąc to 50 story pointów, to znaczy, że aby zrealizować elementy wyszacowane na 300 punktów potrzeba pół roku. Proste? Owszem. Sensowne? Nie, bo to nawet nie prognoza, ale wciąż zaledwie oszacowanie.

Jak to oszacowanie? Cóż, „pół roku” jest przewidywaniem możliwej daty realizacji rozważanych elementów, ale brak informacji, z jakim prawdopodobieństwem została ona ustalona. To optymistyczny scenariusz? Pesymistyczny? Najbardziej prawdopodobny? Nie wiadomo.

Wydawać by się mogło, że posługując się średnią wartością prędkości, tworzymy prognozę najbardziej prawdopodobną, ale tak nie jest. Tak naprawdę wartość średnia nie musi być najbardziej prawdopodobna. Inaczej mówiąc, średnie velocity równe 50 story pointów nie oznacza, że choćby w jednym miesiącu Zespół uzyskał taką właśnie prędkość. Może ta średnia wyliczona została z danych za ostatnich dziesięć miesięcy, w których velocity wynosiło odpowiednio 20, 80, 45, 15, 75, 35, 40, 55, 60 oraz 75 punktów?

Zamiast jednego przewidywania opartego o wartość średnią velocity można sporządzić tych przewidywań kilka. Dobrym pomysłem może być wyliczenie średniej prędkości z trzech okresów, w których była ona najniższa (będzie to takie uśrednione minimum), oraz takiej samej średniej z trzech okresów najlepszych (jako uśrednione maksimum).

Powiedzmy, że to minimum wyniosło 25 story pointów, a maksimum to punktów 75 na miesiąc. Można więc powiedzieć, że możliwe jest, iż praca nad rzeczami wycenionymi na 300 story pointów zajmie rok (wariant pesymistyczny), choć być może uda się ją zrealizować w cztery miesiące (wariant optymistyczny). Widać, że rozrzut między tymi przewidywaniami jest spory, co stanowi silny sygnał, że są one niepewne. I dzięki temu oba razem stanowią prognozę, bo poza informacją ilościową (szacowany czas realizacji) zawiera też informację jakościową, pozwalającą na ocenę jej wiarygodności.

Gdyby velocity rozważanego przykładowego Zespołu wahało się w zakresie 40 do 60 punktów na miesiąc, wariant optymistyczny (ok. 5 miesięcy) od pesymistycznego (ok. 7.5 miesiąca) różniłby się o wiele mniej, co pozwala na nieco większe zaufanie tej prognozie.

Wady prognoz opartych o velocity

Dużą wadą prognoz sporządzonych z użyciem o velocity (ale nie wadą samej prędkości jako miary) jest to, że tworzy się je dość mozolnie, zwłaszcza jeśli ktoś rozważa więcej niż dwa scenariusze. Mówiąc dosadnie, trzeba pieczołowicie nakładać informację o wartości velocity na listę rzeczy do zrobienia, ustalając, gdzie wypadną granice poszczególnych okresów. Okresami tymi są oczywiście takie przedziały czasu, dla jakich wyliczana jest sama prędkość, czyli velocity miesięczne pozwala na przewidywanie, co w którym miesiącu się uda zrobić.

Druga trudność takiego prognozowania polega na tym, że bez wycen nie da się ich sporządzić. I chodzi nie o wyceny tego, co już zostało zrobione, ale o oszacowanie elementów na liście rzeczy do zrobienia.

To wiedzie do trzeciego kłopotu: często rzecz do zrobienia jest tak duża, że jej wycena jest wyższa niż wartość velocity, nawet takiego maksymalnego, jakie udało się Zespołowi kiedykolwiek uzyskać. To oczywisty sygnał, że trzeba dokonać dekompozycji takiego elementu na kilka mniejszych, ale zanim nie zostanie ona przeprowadzona, prognozowanie zaczyna być utrudnione.

Przyjmijmy, że jakiś Zespół osiąga prędkość w iteracji w zakresie 15 do 20 story pointów. W trakcie ustalania, gdzie mogą wypaść granice przyszłych iteracji, okazuje się, że niektóre z nich wypadają w środku elementu na liście, czyli już po rozpoczęciu prac nad nimi, a przed ich zakończeniem. Co wtedy zrobić?

W takim przypadku prognozowane granice iteracji muszą wypadać przed takimi elementami, bo nie chodzi przecież o to, by zacząć pracę nad nimi, ale by je realnie skończyć. Prognoza ma odpowiedzieć na pytanie, kiedy prace zostaną zakończone, a nie kiedy się rozpoczną.

Co jednak zrobić w sytuacji, gdy na liście rzeczy do zrobienia znajdzie się element o wielkości 100 punktów? To oznacza, że realizacja rozłoży się na wiele iteracji. Niekoniecznie trzeba od razu dokonać dekompozycji elementu na wiele mniejszych (a nawet odradzam przedwczesne robienie tego). I tak w przypadku prędkości 20 story pointów na iterację, potrzeba tych iteracji pięć, aby duży element zrealizować. A jeśli prędkość będzie na poziomie 15 punktów, iteracji tych będzie aż siedem (wynik dzielenia zaokrąglony zostaje w górę, żeby nie wygenerować z rozpędu nadmiernie optymistycznego scenariusza).

Prognozy na potrzeby planowania iteracji

Velocity może być użyte nie tylko do prognozowania potencjalnych dat realizacji rzeczy do zrobienia. Wiedzę o uzyskiwanej wcześniej prędkości wiele Zespołów wykorzystuje w trakcie planowanie iteracji (np. Sprintów w Scrumie), żeby na tej podstawie dokonać oceny, co jest możliwe do zrobienia w ograniczonym czasie jej trwania.

Osobiście uważam takie zastosowanie velocity za całkowicie pozbawione sensu z kilku powodów.

Podstawowy problem: punktem odniesienia są w takim przypadku oszacowania elementów z listy rzeczy do zrobienia, które niemal zawsze ustalane są z pewnym wyprzedzeniem, nierzadko wielomiesięcznym (np. w ramach pielęgnacji Backlogu Produktu w Scrumie). Te wyceny uwzględniają co najwyżej stan wiedzy Zespołu w momencie, gdy zostały sporządzane. W szczególności nie było wtedy wiadomo ani kto, ani jak, ani kiedy, ani nawet czy w ogóle ktoś będzie daną rzecz realizował. Nieznany był stan Zespołu w momencie, gdy prace się rozpoczną, dostępność narzędzi, znajomość praktyk itd.

To powoduje, że wiele wycen jest zawyżonych lub zaniżonych w stosunku do tego, w jaki sposób Zespół zdecyduje się zrealizować poszczególne rzeczy. Coś może okazać się łatwiejsze, niżby wynikało to z wcześniejszych szacunków, inna rzecz będzie dla odmiany o wiele trudniejsza. I to właśnie ocena ilości pracy oraz jej czasochłonności powinna być podstawą do decyzji, czy coś może zostać podjęte do realizacji w iteracji.

Pojawia się zatem drugi istotny powód, by nie kierować się wycenami ustalonymi wcześniej. One nie zostały sporządzone w celu zaplanowania konkretnych działań, które wykonane zostaną w określonym momencie. Miały pomóc w lepszym zrozumieniu problemu, podziału dużej pracy na mniejsze kawałki itd. Wszelkie wcześniejsze wyceny będą zawsze dość zgrubne i niepewne w porównaniu do ocen sporządzanych w trakcie budowania planu realizacji tuż przed rozpoczęciem prac.

Ostrzegam Zespoły przed podejmowaniem czegokolwiek do realizacji tylko dlatego, że „velocity wskazuje, że damy radę”. Z tego samego powodu nie warto rezygnować z podjęcia prac nad czymś tylko dlatego, że „velocity wskazuje, że rady nie damy”. Zamiast skupiać się na wycenach wyrażonych np. w story pointach i informacji o prędkości w minionych iteracjach, ludzie powinni poświęcić czas na sporządzenie planu działania, którego czasochłonność będą w stanie oszacować. I to ten plan oraz oszacowanie powinny stanowić podstawę przy podejmowaniu decyzji.

Nie oznacza to, że velocity nie ma żadnego znaczenia w trakcie planowania. Jeśli Zespół dysponuje wiarygodną wartością tej miary, może jej użyć do dodatkowego sprawdzenia swego planu. Krótko mówiąc, informacja o prędkości nie powinna stanowić punktu wyjścia, ale być jedną ze składowych w procesie decyzyjnym, użytą na nieco późniejszym etapie.

Gdy już powstanie jakiś plan, który wydaje się racjonalny, Zespół może ocenić, jaką prędkość potencjalnie osiągnie, jeśli rzeczywiście wszystko przebiegnie zgodnie z przewidywaniami. Zderzenie tej potencjalnej przyszłej prędkości z wartością velocity uzyskiwaną dotychczas może ujawnić, że plan jest przesadnie ambitny albo zbyt zachowawczy. Nie oznacza to, że trzeba go od razu zmieniać, ale jest to dodatkowy wgląd, z którego Zespół może skorzystać.

Przepustowość zamiast prędkości?

O ile velocity wciąż jest dość powszechnie wykorzystywana, rośnie liczba Zespołów, które sięgnęły zamiast niej po przepustowość (ang. throughput). I to niekoniecznie ze względu na ograniczenia czy trudności z użyciem prędkości, ale często po prostu dlatego, że posługują się Kanbanem, w którym niezbędne jest monitorowanie przepustowości – jednej z podstawowych miar przepływu.

W jaki sposób throughput może zastąpić velocity, jakie ma ograniczenia i jakie nowe możliwości daje, wyjaśniam w drugiej części tego niewielkiego cyklu artykułów.