Jak sensownie wykorzystać velocity?

Velocity pokazuje, ile pracy wykonał zespół w określonym czasie. Miara ta jest bardzo popularna. Często jest pierwszym wyborem, choćby dlatego, że bywa gotową opcją w narzędziu do zarządzania produktami. Odcinek ten polecamy wszystkim zespołom i organizacjom, które starają się wykorzystać velocity. Podpowiadamy czego unikać i jak używać porządnie tej miary, a także co zrobić, żeby velocity miało sens.

W każdym procesie, także w procesie scrumowym, aby określić skuteczność wprowadzanych zmian i działań potrzebujemy miary, które pozwolą nam ocenić ich efekty. Popularną miarą w zespołach scrumowych jest Velocity, czyli sposób mierzenia prędkości. 

Oczywiście, zgadzamy się z tym, że velocity nie musi być wykorzystywane przez każdy zespół. Ten artykuł dedykujemy jednak tym zespołom i organizacjom, które z tej miary chcą korzystać lub już korzystają. Chcemy Wam podpowiedzieć jak wykorzystywać velocity w poprawny sposób i czego unikać.

Czego unikać i jak poprawnie wykorzystywać velocity?

1. Velocity może nie mieć sensu, jeśli będzie oparte o godzinowe albo dniowe wyceny.

W takich przypadkach nie będzie ono faktyczną miarą prędkości pracy zespołu. Będzie ono bardziej bliskie jakiejś mierze pojemności, czy możliwości pracy zespołu, gdzie maksimum takiego Velocity będzie taką liczbą godzin lub dni ile zespół ma w ogóle do dyspozycji. 

W takich przypadkach Velocity będzie pokazywało tylko czy zespół wyrabia to oczekiwane maksimum czy nie. Ponadto ograniczeniem zawsze będzie maksymalna możliwa pojemność zespołu (capacity), czyli ilość godzin i ilość dni, które dany zespół ma do dyspozycji na pracę. To będzie bardziej zabawa w raportowanie godzin.

Takie velocity może wydawać się całkiem stabilne, bo zespół będzie mniej więcej zazwyczaj w okolicy tej samej ilości godzin. Jednak wynika to tylko z tego, że to nie jest prędkość zespołu, a po prostu ile godzin, ile dni do dyspozycji ten zespół miał w ramach danego Sprintu. Takie podejście nie ma sensu, bo bazujemy na niewłaściwej liczbie, która nie daje podstaw do wyciągania dalszych wniosków. 

Żeby velocity jako miara prędkości zespołu w ogóle miało sens, trzeba bazować na faktycznych Story pointach. Muszą być one stabilne w czasie, czyli w różnych momentach pracy danego zespoły muszą oznaczać mniej więcej podobną wielkość czy złożoność pracy do wykonania. Dobrze też, aby miały stabilną skalę w długim horyzoncie czasowym. 

Więcej o Story pointach i generalnie o estymowaniu mówiliśmy w odcinku #19 podcastu, do którego wysłuchania Cię zapraszamy. 

W sytuacji, gdy nie mamy Story pointów, a elementy w Backlogu Produktu są podobnie małe, można oprzeć statystykę prędkości na liczbie elementów z Backlogu Produktu, które zostały ukończone. Mówimy tutaj bardziej o takiej przepustowości. Jednakże warunkiem koniecznym tu jest to, że elementy, które przechodzą nam przez proces, muszą być podobnej wielkości, a wszystkie elementy, które będą wyjątkowo większe, albo wyjątkowo mniejsze, będą ten odczyt zakłócać.

Velocity bazujące na liczbie elementów jest po prostu sumą tych elementów w danym Sprincie, który porównujemy z poprzednimi Sprintami. Na odpowiednim poziomie ogólności, przy odpowiednio dużej puli tych elementów, będą do siebie wystarczająco podobne, żeby te trendy dawały nam jakiś obraz. 

2. Velocity powinno reprezentować faktycznie ukończone kawałki produktu.

W przypadku Scruma mamy tu na myśli przyrost produktu. 

To co czym określamy jako “ukończone” jest kwestią umówienia się w zespole i ustalenia wspólnej definicji tego. Ważne jest tu, że nie interesuje nas prędkość czystego developmentu (np. bez testów czy integracji), a to, co zliczamy do velocity, powinno być gotowe do użycia przez osoby odpowiedzialne za biznes. 

Niepokojącym zjawiskiem w tym obszarze jest naciąganie statystyk i naliczanie sobie Story pointów za zadania poboczne (np. warsztaty i szkolenia), które nie przynoszą wartości dodanej do produktu i tylko zaburzają statystykę. To trochę oszukiwanie samych siebie.

Żeby velocity było dobrze stosowane warto mieć bardzo rzetelne Definition of Done, czyli definicję ukończenia. Oczywiście należy też tej definicji w sposób zdyscyplinowany przestrzegać w każdym Sprincie i co do każdego elementu. Trzeba zaakceptować fakt, że w niektórych Sprintach nie uda się ukończyć żadnego elementu i wówczas velocity wyniesie 0. To zresztą jasno pokaże, jaka jest zdolność zespołu do dostarczania przyrostu produktu, bez tłumaczenia się zajętością i zajmowania się wieloma zadaniami naraz (i nieukończeniem przez to żadnego zadania).

3. Velocity powinno być wykorzystywane do planowania kolejnych Sprintów.

Spotykamy się z sytuacjami, gdzie zespół planuje więcej, niż jest w stanie zrealizować, bo Velocity jest mierzone, ale nie jest realnie wykorzystywane do planowania kolejnych Sprintów. Może to powodować frustrację zarówno po stronie biznesowej, jak i w samym zespole. Biznes nie otrzymuje tego, co miał obiecane, z kolei sam zespół może mieć poczucie, że cały czas nie realizuje celów. 

Dlatego skoro velocity jest już mierzone, to warto je używać np. do planowania pojemności pracy w kolejnym Sprincie, refleksji na temat tego, ile jesteśmy w stanie jako zespół faktycznie wziąć do kolejnego Sprintu. Pamiętajmy jednak, że to tylko pewna wskazówka, zależna od innych czynników, jak np. składowa zespołu, które również należy uwzględnić podczas planowania. 

4. Velocity nie jest wykorzystywane do planowania długofalowego.

Niebezpiecznym zjawiskiem jest sytuacja, w której velocity jest naprawdę rzetelne i zespół w miarę ufa swoim danym, ale w dłuższym horyzoncie czasowym bazuje z powrotem na jakimś na przykład wyczuciu lub daty ukończenia pewnych elementów są wymuszone z zewnątrz. 

Podobnie, jak w poprzednim przypadku, zespół w zasadzie ma całkiem dobre podstawy do bardziej realistycznego planowania prac, jednak ich nie wykorzystuje i marnuje okazję do dobrych wyników.  

Należy tu jednak pamiętać, że przy planowaniu długoterminowym nie ma sensu robić super precyzyjnych prognoz, bo najprawdopodobniej Backlog Produktu zmieni się wielokrotnie. Velocity po prostu ułatwia nam oszacowanie bardziej odległych dat ukończenia poszczególnych elementów produktu.

5. Nie porównuj velocity pomiędzy zespołami

Jest to szczególnie ważne zwłaszcza z perspektywy managementu albo Product Ownera pracującego z kilkoma zespołami.

Należy mieć w pamięci, że 30 Story pointów w jednym zespole, a 30 Story pointów w drugim zespole, to będą inne wartości. Ponadto to, że jeden zespół ma 100 Story pointów, a drugi ma 50, nic nie znaczy – ten drugi wcale nie musi być o połowę gorszy od pierwszego. 

Zespoły mogą mieć różną charakterystykę pracy, inne zadania do wykonania, bardziej czasochłonne technologie. Doświadczenie członków zespołów może być różne albo zespoły powstały w różnym czasie i dopiero uczą się współpracować.

Sensowne jest zatem pozostać z analizą velocity w obrębie konkretnego zespołu. 

Przeglądajcie je regularnie na Retrospektywie Sprintu i podczas dyskusji dotyczących usprawnień bierzcie pod uwagę jako jeden z argumentów. Ważne jest też, aby nie patrzeć tylko na samą liczbę, ale też na trendy, czy przyczyny zmienności, które obserwujemy.

Dodatkowo, jeśli trudno ustalić jakiś ogólny trend w osiąganym velocity i przykładowo zespół robi w jednym sprincie 20 Story pointów, a w drugim 80, a w trzecim 50, a w czwartym 35, to warto przyjrzeć się, dlaczego tak jest. Zwłaszcza management powinien się zainteresować powodem takich losowych wyników. Może zespół potrzebuje wsparcia albo pojawiają się wyraźne przeszkody w pracy. Z drugiej strony, pozytywne skoki w górę mogą wiązać się z jakimś eksperymentem i innym podejściem do współpracy w zespole, który warto wykorzystać w kolejnych sprintach i w innych zespołach. 

6. Nie traktuj velocity jako na miary efektywności.

Mamy tu na myśli dostarczaną przez zespół wartość. Bardzo łatwo popaść w złudzenie, że jeśli velocity rośnie, to możemy mówić o sukcesie zespołu. Natomiast prawda jest taka, że jakość tego, co zespół oddaje nam jako efekt pracy, bardzo mocno zależy od wsadu początkowego, czyli tego co znajduje się w Backlogu Produktu. 

Obrazując to na przykładzie: w obecnie produkowanych autach na wyświetlaczu widać różne statystyki dotyczące tego ile przejechaliśmy kilometrów, czy jakie mamy średnie prędkości przejazdu od ostatniego zresetowania licznika. I właśnie tutaj ta średnia prędkość przejazdu nie oddaje całkowitej rzeczywistości, bo zależy ona od wielu czynników. Jak jadę wiele godzin po autostradzie, to ta średnia prędkość będzie wysoka. Jak jadę w korku po mieście, to ona będzie niższa. W gruncie rzeczy, to czy jadę szybko, czy jadę wolno, niespecjalnie mi mówi cokolwiek o efektywności mojej jazdy, rozumianej jako osiąganie tego efektu, czyli zmierzania do celu. Ponadto średnia prędkość niespecjalnie będzie miała ścisły związek z tym, ile jeszcze nam czasu na dotarcie do celu zostało. Bo może się okazać, że jedziemy zupełnie nie w tę stronę. Czyli szybsze jechanie w niewłaściwym kierunku nie przybliża nas do mety. A z tych statystyk da się wyciągnąć o wiele więcej, np. średnie spalanie, czyli jak wygląda strona kosztowa naszej pracy. Z kolei nawigacja live może nam podpowiedzieć lepszą trasę, mimo że wcześniej wskazana była inna.

Porównując to do zespołów, to  jeśli nie mierzymy efektywności, nie zastanawiamy się nad tym, co nas przybliża do celu i nie konfrontujemy się z tym w miarę regularnie, no to niestety możemy szybko, zgodnie z pierwotnym planem, działać nie w tym kierunku co trzeba. 

Co zatem można zrobić zamiast tego? Trzeba stworzyć i używać miary efektywności dla danego zespołu. Tak jak velocity może być tą miarą prędkości w miarę uniwersalną, tak miara efektywności pracy zespołu, miara dostarczonej wartości biznesowej, to jest coś, co jest dosyć unikalne dla danego produktu, czy dla danej branży. Może to być np.:
– średnia wartość koszyka, 

– przychód per klient,

– czas onboardingu nowego klienta,

– średni czas, jaki użytkownik spędza, konsumując treści w aplikacji.

To mogą też być miary mniej policzalne w pieniądzach czy jednostce czasu, jak np. miara bezpieczeństwa, jakie zapewnia zespół czy miara satysfakcji pracownika. Opcji jest wiele, ważne natomiast jest to, aby każdy zespół zdefiniował, co jest w jego przypadku wartością biznesową i jak ją będzie mierzył. 

Podsumowując, jak zatem sensownie wykorzystać velocity?

• Bazuj na poprawnych danych.
• Do statystyki włączaj tylko faktycznie skończone elementy.
• Używaj velocity do planowania  krótkoterminowego i długoterminowego.
• Analizuj wyniki velocity podczas Retrospektyw Sprintu.
• Oprócz miary prędkości mierz też dostarczoną wartość biznesową.

Velocity jest tylko jednym z przykładów praktyk zwinnych, które dosyć często są błędnie implementowane przez zespoły oraz firmy. Jeżeli Scrum w twoim zespole lub w twojej firmie nie przynosi takich efektów, jak się spodziewasz, to jest duża szansa, że wynika to z błędów implementacji tego frameworka. Dlatego nie krępuj się i napisz do nas, z chęcią pomożemy zdiagnozować problemy w Twoim zespole i zarekomendować sprawdzone sposoby, jak można je rozwiązać.

Dodatkowe materiały

• Estymowanie

Współpraca z nami

Velocity jest tylko jednym z przykładów praktyk zwinnych, które są często błędnie implementowane. Jeżeli Scrum w Twoim zespole lub firmie nie przynosi takich efektów, jakich się spodziewasz, jest szansa, że wynika to z błędów w implementacji tej metody.

Pomagamy firmom zdiagnozować problemy i rekomendujemy sprawdzone sposoby, jak można je rozwiązać. Mamy dowody z rynku na to, że nasze ekspercie spojrzenie z zewnątrz przynosi wartość. Skontaktuj się z nami przez formularz na stronie porzadnyagile.pl/kontakt. Z przyjemnością podzielimy się z Wami swoją wiedzą i doświadczeniem, których tu nie mamy możliwości w pełni przekazać.

Transkrypcja podcastu „Jak sensownie wykorzystać velocity?”

Jacek: Kiedy pracujemy z klientami, obserwujemy, że velocity, czyli sposób na mierzenie prędkości, jest bardzo popularną miarą wśród zespołów. Z jednej strony bardzo często management potrzebuje jakiejś miary i velocity w przypadku wykorzystywania podejścia zwinnego, okazuje się ich pierwszym wyborem. Czasem jest tak, że jakaś aplikacja, jakiś produkt, który zespół wykorzystuje do zarządzania zadaniami, taskami elementami w Backlogu Produktu również proponuje velocity jako miara, która po prostu jest dostępna z pudełka. A czasem wcześniejsze doświadczenia osób w zespole doprowadzają do tego, że zespół decyduje się wykorzystywać velocity jako główna miara, która pokazuje prędkość, z jaką pracuje zespół. 

Jacek: Na początku tego odcinka chcielibyśmy przypomnieć o trwającym badaniu Słuchaczy Podcastu Porządny Agile. To już drugie badanie. Zbieramy informacje od Słuchaczy, które pozwolą nam lepiej zrozumieć, kto aktualnie nas słucha i lepiej dopasować treści dla naszych Słuchaczy. Tak więc zachęcam Cię Słuchaczu, Słuchaczko do poświęcenia dosłownie kilku minut na wypełnienie ankiety. Jest dostępna ona pod adresem porządnyagile.pl/ankieta. Na Twój głos czekamy do 17 listopada 2021. 

Kuba: Przechodząc z powrotem do treści odcinka, zaznaczmy na początku, że zgadzamy się z takim stwierdzeniem, że velocity można nie wykorzystywać w ogóle. Czyli nie będziemy się tutaj rozprawiali nad wszystkimi możliwymi sposobami mierzenia, ani nie będziemy też rozmawiać o powodach niewykorzystywania velocity. Ten odcinek jest dedykowany tym zespołom i tym organizacjom, które z tej miary starają się korzystać i chcemy podpowiedzieć jak robić to porządnie. Podpowiemy czego unikać i jak wykorzystywać velocity w poprawny sposób. To przechodząc do meritum Jacek, jaka jest nasza pierwsza przestroga w tym temacie?

Jacek: Pierwsza przestroga, którą chcemy się z Tobą podzielić, jest taka, że velocity może nie mieć sensu, jeśli będzie oparte o godzinowe albo dniowe wyceny. Są zespoły, które z różnych powodów decydują się na takie uproszczenie. Czasem wynika to z niewiedzy, czasem wynika to z presji managementu, czasem z niezrozumienia, dlaczego w ogóle mielibyśmy stosować miarę taką jak Story Pointy. No i dochodzi do takich popularnych przełożeń, gdzie zespół się umawia, że jeden dzień to jest jeden Story Point, albo jeden dzień to są dwa Story pointy itd.

Kuba: Takie velocity wtedy nie będzie faktyczną prędkością pracy zespołu, tylko bardziej będzie bliskie jakiejś miary pojemności, możliwości pracy zespołu, albo nazwijmy to bardzo brzydko – utylizacji czasu pracy zespołu – gdzie zespół po prostu w maksie takiego velocity będzie miał tyle godzin, albo tyle dni ile ma w ogóle do dyspozycji. No i ewentualnie to velocity będzie pokazywał czy wyrabiamy tego oczekiwanego maksa, czy może coś nie do końca udało się zrobić. Natomiast to tutaj jakby sufitem zawsze będzie maksymalna możliwa pojemność zespołu. Może plus minus jakieś mikro przyspieszenie, ale tak naprawdę ta miara, tak upraszczając będzie oscylowała wokół mniej więcej capacity zespołu, czyli ilości godzin i ilości dni, który ten zespół ma do dyspozycji na pracę. No i raczej będzie to gra, czy zabawa w raportowanie godzin. Takie velocity jakby rzucić na nie okiem, może się nawet wydawać całkiem stabilne, bo zespół będzie mniej więcej zazwyczaj w okolicy tej samej ilości godzin. No, ale powiedzmy sobie szczerze, to wynika tylko z tego, że to nie jest prędkość zespołu, tylko po prostu ile godzin, ile dni do dyspozycji ten zespół miał w ramach danego Sprintu. No i jeśli są jakieś korzyści czy sens istnienia velocity, o czym będziemy mówić w kolejnych poradach i przestrogach, to akurat tutaj to wszystko jest przekreślone. Bo tak naprawdę bazujemy na niewłaściwej liczbie i z tych niewłaściwych liczb wyciąganie dalszych wniosków już w zasadzie nie ma za bardzo sensu. 

Jacek: Czyli właściwie nie mówimy tutaj o prędkości. To jest bardziej przepracowany czas, nie ma to nic wspólnego z velocity zespołu. No więc, co wobec tego Kuba robić, żeby to miało sens? Jak to policzyć?

Kuba: Żeby velocity jako miara prędkości pracy zespołu miało sens, trzeba bazować na faktycznych Story pointach. Faktycznie zdrowo rozumianych, dobrze zbudowanych. Muszą one być stabilne w czasie. Czyli w różnych Sprintach, czy w różnych momentach pracy danego zespołu te Story pointy muszą mniej więcej oznaczać podobną wielkość, czy podobną złożoność pracy do wykonania. Najlepiej gdyby to było ze stabilną skalą, też z jakimiś takimi referencyjnym historykami czy referencyjnymi elementami, które pokazują nam pomiędzy wieloma Sprintami, że dwa Story pointy to ciągle oznacza tą samą złożoność pracy, niezależnie od tego jak szybko, w tym, czy w tamtym Sprincie to realizowaliśmy. 

Jacek: Więcej o Story pointach i generalnie o estymowaniu możesz usłyszeć w odcinku 19. Natomiast może przychodzić Ci do głowy pytanie. Co jeśli nie masz Story pointów? Jest wyjście z takiej sytuacji. Generalnie, jeżeli elementy, które masz w Backlogu Produktu są podobnie małe, można oprzeć statystykę prędkości na liczbie elementów z Backlogu Produktu, które zostały skończone. Czyli bardziej mówimy tutaj o takiej nazwijmy to – przepustowości. Natomiast takim warunkiem koniecznym, żeby to zadziałało musi być to, że elementy, które przechodzą nam przez proces, muszą być po prostu podobnej wielkości. Czyli wszystkie elementy, które będą wyjątkowo większe, albo wyjątkowo mniejsze, będą nam ten odczyt zakłócać.

Kuba: I jak wtedy takie velocity bazujące na ilości działa? No po prostu podsumowujemy ile jakichś elementów, ficzerów, taksów… Może nie tasków, bo to bardziej z zadaniami się kojarzy. Ale jakieś te elementy, które przetworzyliśmy, po prostu sumujemy ich ilość. Czyli zrobiliśmy 10 elementów w tym Sprincie. W kolejnym zrobiliśmy dziewięć. W kolejnym 11. No i wyciągamy sobie na tej bazie wnioski. Jeśli te elementy były wystarczająco blisko podobnej wielkości, to tak naprawdę może nie musimy schodzić na poziom bardzo dużego szczegółu. Czy to były dwa Story pointy, trzy Story pointy, czy one się tam różniły plus minus o parę procent? No bo tak naprawdę na odpowiednim poziomie ogólności, przy odpowiednio dużej puli tych elementów, po prostu one będą do siebie wystarczająco podobne, żeby te trendy, żeby te analizy, żeby ta metryka przez wiele Sprintów też nam coś fajnego mówiła. To akurat będzie dosyć trudne do uzyskania. Na przykład w Jirze, jeśli metryka mierzy się na estymatach, bo tutaj nie będziemy mieli tych estymat, no ale może też łatwy taki hak na system, to po prostu w estymacie zawsze wpisać jeden. No i wtedy będziemy mieli jeden element, to jest jeden punkt i wykres będzie nam się budował na ilości elementów jednopunktowych, które zrobiliśmy na przykład w danym Sprincie czy przez wiele Sprintów. 

Jacek: Kolejna przestroga, którą mamy, jeżeli chodzi o velocity, to bardzo mocno rekomendujemy, żeby velocity reprezentowało faktycznie ukończone kawałki produktu. Jeśli mówimy o Scrumie, to myślimy tutaj o przyroście produktu. Jeżeli generalnie pracujesz zwinnie, albo nawet w sumie niekoniecznie zwinnie, no to po prostu rzeczy, które są skończone. I tutaj oczywiście, co to znaczy skończone? To jest kwestia pewnego umówienia się i definicji. No ale w szczególności nie interesuje nas prędkość czystego developmentu, na przykład bez testów, albo bez integracji, albo bez merdża. I tak dalej. Czyli generalnie chcielibyśmy, żeby prędkość była odzwierciedleniem naszego tempa oddawania z biznesowego punktu widzenia skończonych przyrostów produktu. Czyli w momencie jak mówimy, że coś jest skończone, zliczamy sobie to do velocity, no i to powinno być gotowe dla osób biznesowych, żeby po prostu tego użyć. 

Kuba: No i idąc dalej z przestrogą. Jacek mówisz o przypadku gdy na przykład jest zaliczany punkty za development, ale bez testów. Ja też czasami obserwuję bardzo niepokojące zjawisko takiego trochę odgrywania statystyki, poprzez tworzenie sobie zadań i naliczania sobie za nie Story pointów. Zadań, które nie są w ogóle żadnym rozwojem produktu. Na przykład pół zespołu idzie na dwa dni na szkolenie i sobie gdzieś tam wykalkulowują, że to w takim razie to jest 5 Story pointów i velocity się buduje ładnie i będzie stabilne. Nie będzie żadnych spadków za to, że przez kilka dni członków zespołu nie było do dyspozycji w Sprincie, więc statystyka się zgadza. No ale niestety jesteśmy teraz w tym świecie, czy w tym momencie rozmowy jesteśmy w tematach jakby rzeczy, których należy unikać. No i to niestety jest bardzo brzydkie granie statystykami, gdzie sobie zaliczamy jakieś punkty za jakieś warsztaty, za jakieś szkolenia, za jakiejś aktywności poboczne, które kompletnie nie przynoszą wartości dodanej do produktu i to jest jakby jedna kwestia. Co gorsza, zaburzają nam statystykę. Więc jeśli będziemy chcieli tego velocity używać, żeby traktować to jako poważna miara, no to tak naprawdę fałszujemy dane i na bazie sfałszowanych danych później się pocieszamy, że jest dobrze. Nie, nie jest dobrze. 

Kuba: Gdy trochę już zapowiedziałeś, co można z tym zrobić. No i tutaj, co robić w tej sferze, żeby velocity było dobrze stosowane? No mieć bardzo rzetelne Definition of Done, czyli definicję ukończenia. I faktycznie bardzo konkretnie bardzo, bardzo zdyscyplinowany sposób tej definicji przestrzegać, w każdym Sprincie i co do każdego elementu. Czyli może się tak zdarzyć, że jeśli wliczamy do velocity wyłącznie ukończone kawałki produktu, to w takich najgorszych Sprintach nie uda się tak autentycznie ukończyć nic. A i będziemy mieli velocity równe zero, albo bardzo tego zeru bliskie. I to jest rzeczywistość. Ona jest najbardziej brutalna. Najbardziej niekorzystna, jeśli ktoś tam chciałby zacząć się przejmować tą miarą, ale autentycznie, akurat w tym Sprincie po prostu ukończyć wszystkiego się nie udało i velocity wynosi zero. 

Jacek: W skrajnym przypadku to może być sytuacja, w której wszyscy bardzo mocno się napracowali, no i przychodzi ten smutny moment takiej frustracji. No to dlaczego mamy zero punktów? I generalnie moim zdaniem to jest kwestia, w jaki sposób tę naszą zdolność produkcyjną wykorzystujemy. No bo możemy sobie rozgrzebać bardzo dużą ilość zadań i prawie je ukończyć i mieć takie poczucie, że prawie zrobiliśmy. No ale, jeżeli spojrzymy na to z perspektywy biznesowej, no to mamy wszystko rozgrzebane, nic skończone. No czyli prędkość jest zero, bo gotowych rzeczy, które rozszerzają, poprawiają, ulepszają nasz produkt, po prostu nie ma. Tak konstruowane velocity jak przed chwilą z Kubą powiedzieliśmy, bardzo fajnie pokazuje zdolność zespołu do dostarczania przyrostu produktu. 

Jacek: Trzecia przestroga, którą dla ciebie mamy jest taka, że jeżeli mamy już velocity, no to warto zwrócić uwagę na to, czy faktycznie wykorzystujemy tę miarę do planowania kolejnych Sprintów. Spotykam się z sytuacją, że dostajemy taką liczbę z pudełka, z jakiegoś produktu w stylu Jira. Czasem jest tak, że Scrum Master liczy sobie to gdzieś na boku w Excelu. Czasem nawet Product Ownerzy z tego korzystają. Natomiast jest liczba, jest prowadzona nawet jakaś tam historia, ale nie jest to realnie wykorzystywane w trakcie planowania, co bardzo często przekłada się na to, że zespół planuje więcej, niż jest w stanie zrealizować. Co zarówno może powodować frustrację po stronie biznesowej, na zasadzie, obiecujecie – nie dostarczacie, ale działa to też na sam zespół, który może mieć takie poczucie, że cały czas nam nie wychodzi.

 Kuba: I traktowałbym to też jako po prostu traconą okazję czy marnowaną szanse na to, że w zasadzie mamy już jakąś dostępną składową do tego, żeby być lepszym zespołem, tylko z jakiegoś może nieznanego powodu, po prostu tego nie wykorzystujemy. Więc tutaj przestroga nasza o tym, że jeśli już masz velocity, to po prostu zacznij go używać. Na przykład do planowania pojemności pracy w kolejnym Sprincie, refleksji na temat tego, ile jesteśmy w stanie jako zespół faktycznie wziąć do kolejnego Sprintu. No i to jest to, co powiedziałem, to jest w zasadzie już od razu konkretna porada. Możemy stosować velocity, jeśli wierzymy, jeśli wypełniliśmy te dwa poprzednie punkty, które wspomnieliśmy przed chwilą. Czyli bazujemy na rzetelnych danych, faktycznie na zadaniach skończonych, no to ta statystyka zaczyna mieć dla nas znaczenie. Ufamy jej i może ona nam podpowiadać, że na przykład w naszym zespole realnie Sprint w Sprint mniej więcej typowo wytwarzamy czy kończymy około trzydziestu Story pointów. Więc jeśli na kolejny Sprint wygląda na to, że się zabieramy za na przykład 50 Story pointów, to tutaj naprawdę znak zapytania, czy to jest realistyczne. Może akurat w jakimś fajnym, optymistycznym założeniem się da, ale możliwe, że trzeba przyjąć trochę bardziej realistyczne albo pesymistyczne założenie, że skoro Sprint w Sprint wyrabiamy mniej więcej 30, to nagle magicznie tych 50 to jednak nie uda się zrobić. 

Jacek: No i warto tutaj dodać, że sama ta liczba historyczna, którą mamy, no to to jest tylko pewna wskazówka. W sensie widywałem zespoły, które bardzo literalnie potrafiły traktować velocity. Czyli jak było 34 w ostatnim Sprincie, no to dokładnie w tę liczbę próbowały celować. Trochę mam wrażenie zapominając, że oczywiście ta prędkość jest zależna od składu zespołu, od tego, czy przykładowo sobie jakoś tam ze względu na jakieś święta nie wydłużyliśmy Sprintu, żeby nam coś pasowało, bo też takie manewry spotykam w zespołach. Czy być może właśnie zaczynamy pracować nad jakimś nowym obszarem produktu, który jest dla nas nowy? Tak więc wszystkie te rzeczy, które wymieniłem, mogą wpłynąć na naszą zdolność wytwarzania. Tak więc ja jestem fanem tego, żeby kiedy mamy już velocity, no to traktować je jako taki dodatkowy czynnik, czy dodatkową może informację bardziej, która może nam pomóc w planowaniu, ale nie zastąpi to na pewno zdrowego rozsądku.

Kuba: Czwartą przestrogą, którą chcemy wymienić to przypadek, w którym zespoły mają velocity, ale nie wykorzystują go do planowania na kolejne Sprinty, albo takiego planowania już na wiele Sprintów już od takiego długofalowego. To jest bardzo niebezpieczne zjawisko, w którym, nawet jeśli założymy, że to velocity jest naprawdę rzetelne i zespół w miarę ufa swoim danym, to w dłuższym horyzoncie bazuje z powrotem na jakimś na przykład wyczuciu. Czyli Product Owner, albo na jakimś pierwszym Refinemencie stwierdzamy – dobra damy radę 6, 9 miesięcy albo 6, 9 Sprintów lub mimo że zespół ma w zasadzie podstawy do tego, żeby dosyć rzetelnie prognozować, bazując na pewnych statystykach, to na przykład terminy czy na przykład zakresy pewnych prac na dane daty, pojawiają się zupełnie arbitralnie, na wyczucie, albo wręcz są na zespole wymuszone. Czyli znowu jak w poprzednim przypadku zespół w zasadzie ma całkiem fajne podstawy i niestety marnuje okazję do tego, żeby wykorzystać dosyć rzetelne narzędzia do tego, żeby planować sobie pracę, czy planować pewne daty, pewne zakresy w dłuższym horyzoncie czasowym.

Jacek: No i to, co można zrobić tutaj? No generalnie wykorzystać to, że wiemy, jaka jest nasza prędkość do prognozowania długofalowego. I tutaj myślę, że na dwie rzeczy trzeba zwrócić uwagę. Po pierwsze, to jest prognozowanie i jakość tej prognozy jest bezpośrednio skorelowana z tym jakiej jakości mamy estymaty. Druga sprawa jest taka, że żeby dokonać takiego bardziej długofalowego spojrzenia na przykład na kilka Sprintów w przód, albo kiedy wypuszczamy większą zmianę w produkcie i chcemy ją wypuścić w całości, ona składa się z mniejszych elementów. No to musimy mieć wyestymowane te rzeczy w przód. No i oczywiście im dłużej w przód estymujemy, tym myślę, że ta trafność może być gorsza. Na pewno tutaj warto byłoby rozważyć jakieś takie wytwarzające się marnotrawstwo, na zasadzie, no nie ma też sensu mieć super precyzyjnych prognoz na rok w przód, no bo najprawdopodobniej do tego czasu Backlog Produktu się zmieni. Natomiast takie zdrowo rozumiane prognozowanie najbliższych naszych kroków, relatywnie prosto jesteśmy w stanie zrobić. I daje to jakieś tam, jakąś bazę, w szczególności dla osoby takiej jak Product Owner do podejmowania decyzji, do komunikowania też kolejnych kroków, czy na rynek, czy trochę tak wyżej, tak po prostu do interesariuszy konkretnego produktu. 

Kuba: Ale ja tutaj zaznaczę taki trochę głos odrębny do tego, co do tej pory padło, że na pewno nie jest tak, że jest prognozowanie na velocity i wiele Sprintów w przód albo tylko planowanie najbliższego Sprintu czy tego Sprintu, w którego trakcie jesteśmy. Jeśli jesteśmy w takiej sytuacji, że mocno istotne czy mocno krytyczne jest to czy się wyrobimy na przykład na jakąś datę wdrożenia. To możliwe, że odrobina planowania w przód takiego bazującego na velocity, ale również realizowanego poprzez pewne jakby oszacowanie i przymierzenie się do zadań, zbudowanie pewnego planu kolejnych kroków. Również więcej niż jeden Sprint bieżący może być rozsądnym wyborem. Czyli podsumowując tę myśl, długofalowo bazuje na prognozach na velocity, ale jeśli życie naszej firmy, albo sens istnienia naszego produktu jednak zależy od tego, że uda nam się Sprint plus jeden od tego, w którym jesteśmy, to być może nie ma nic złego w tym, żeby sobie też go po prostu jakoś roboczo zaplanować i na planowaniu kolejnego Sprintu powtórzyć ten plan i upewnić się, że to się wszystko składa do kupy. No a poprzez negatyw powiem, czasami ta statystyka, że w ostatnich pięciu Sprintach robimy 30 Story pointów, to w kolejnym też zrobimy 30 Story pointów, może nas naprawdę mocno zawieść, jeśli się okaże, że akurat niekorzystnie na przykład się po układały elementy i no niekoniecznie jesteśmy w stanie je tak sprawnie wyrobić na tę datę, jak sobie wszyscy wymarzyliśmy. 

Kuba: Następna przestroga, co do stosowania velocity wydaje mi się dosyć pewniakiem, ale i tak ją wymienię. To to, żeby nie porównywać velocity pomiędzy zespołami. To jest chyba klasyk, na każdym szkoleniu powinien przynajmniej, mi się wydaje być. Zwłaszcza jeśli mówimy o perspektywie osób pracujących z kilkoma zespołami. Na przykład Product Ownera pracującego z więcej niż jednym zespołem albo managementu, który jest ponad zespołami, czy mających wszystkie zespoły w firmie, czy tylko część pod swoim zarządzaniem. Velocity nie porównujemy pomiędzy zespołami i ten klasyk, o którym mówi o tym, że po prostu 30 Story pointów w jednym zespole, a 30 Story pointów w drugim zespole, to będą po prostu jakieś inne wartości, bo tę skalę tych zespołów są po prostu różne od siebie i to nic nie znaczy, że jakiś zespół ma 100 Story pointów, a inny ma 50, to nie znaczy, że ten drugi jest o połowę gorszy, czy cokolwiek tutaj mogłoby nam do głowy przyjść.

Jacek: Te zespoły mogą mieć też różną charakterystykę pracy, czyli przykładowo te zespoły, które robią bardziej innowacyjne produkty, używając nowej technologii. Albo są to po prostu nowe zespoły, no to w ich pracy jest trochę więcej niepewności. Stąd te estymaty mogą być trochę gorsze, to velocity może trochę bardziej skakać trochę mniej wyraźnie pokazywać, jaka jest faktyczna prędkość zespołu. Więc ten aspekt też trzeba byłoby wziąć pod uwagę, zanim tak trochę bezrefleksyjnie powiemy – Ten zespół zobacz jak stabilnie pracuje, a ten cały czas coś. To mogą być racjonalne argumenty pod spodem, które będą na to wskazywać. Co więc robić? Sensownie jest, jeśli z tą analizą prędkości pozostaniemy w obrębie konkretnego zespołu. Przyniesienie sobie na Retrospektywę Sprintu czy wykresu wielkości, czy jakichś danych i poddanie tego pod dyskusję, uważam za bardzo sensowną rzecz. Sam rekomenduję takie postępowania zespołom, w szczególności, jeśli są dopiero na początku swojej drogi. Jeśli chodzi o badanie czy przewidywalność, czy velocity, żeby literalnie mieć przestrzeń na każdej Retrospektywie, żeby spojrzeć na wyniki i zastanowić się, jeżeli były gorsze, co na to wpłynęło? Jeżeli były lepsze co na to wpłynęło z tego wyciągnąć wnioski. Jak słyszę, że zespoły nie robią Retrospektywy, bo w sumie nie ma już co usprawnić, to pewniakiem dla mnie jest, że jak sobie weźmiemy jakąś miarę i zastanowimy się, z czego to wynika? Ale tak naprawdę jak się zastanowimy trochę głębiej, to zwykle wychodzą naprawdę bardzo fajne usprawnienia, które też obserwuję, że bardzo często w widoczny sposób przekładają się na to, że zespół faktycznie poprawia swoją czy prędkość, czy efektywność, czy cokolwiek, na co tam zwracamy uwagę tak więc bardzo ważna rzecz, żeby znaleźć czas na analizę miar, na które zwracamy uwagę, bo w tym przypadku mówimy konkretnie o wielości. 

Kuba: Do tego, co Jacek mówisz, ja bym jeszcze dorzucił taką poradę o tym, żeby patrzeć nie tylko na suchą liczbę, ale też na trendy. Czyli rzucić okiem czy nam to velocity spada, jest stabilny czy może rośnie? Nie jestem wielkim fanem takiego fetyszu, że ono musi koniecznie rosnąć. Ale gdyby spadało, albo gdyby w bardzo długim okresie pomimo wielu, wielu, wielu usprawnień, które podejmujemy i mamy poczucie takie subiektywne, że jest ciągle lepiej, a velocity tego nie oddaje, to może się okazać, że jednak tutaj dajemy się jakiemuś złagodzeniu lub dzieją się jakieś zjawiska niekorzystne, których na razie nie wyciągnęliśmy na światło dzienne. Czyli ten trend, to jest jedna sprawa, a druga sprawa to też taka bardziej perspektywa odchylenia. Czyli czy to w velocity jest w miarę ustabilizowane. Nie mówię, że za każdym razem dokładnie trafiamy w liczbę, ale gdzieś tam oscylujemy wokół pewnego odchylenia, a nie, że skaczemy od zera do stu i gdzieś tam po drodze dosyć losowe wartości, z których w sumie nie umiemy nic wyciągnąć, nic wywnioskować. Zwłaszcza wtedy ta średnia mediana, czy jakąkolwiek statystyczną analizę poddamy, takie velocity, które jest bardzo rozedrgane. Ona może nie mieć za bardzo sensu. To znaczy, jeśli zespół robi w jednym sprincie 20, a w drugim 80, a w trzecim 50, a w czwartym 35, to tak naprawdę nie mam pojęcia, ile zrobią w kolejnym Sprincie, który ich czeka, albo w kolejnych 5 Sprintach, na które na przykład prognozują pracę. No i wtedy też bardzo bym się zaciekawił. To jest taka porada dla managementu, no co takiego się w tym zespole dzieje, że to velocity tak losowo skacze. Bo być może ten zespół potrzebuje pomocy, być może ten zespół ma jakieś wyraźne przeszkody, które im tam bardzo przeszkadzają. A z perspektywy może optymistycznej, czy pozytywnej, może te wyskoki pozytywne w górę, to są te przypadki, gdzie ktoś zrobił bardzo ciekawy eksperyment, trochę inaczej się zabrał na przykład do współpracy w zespole. Może inaczej zorganizował plan? Tylko to nie zostało dostrzeżone, nie wygenerowaliśmy sobie odpowiednio głębokich spostrzeżeń. Nie połączyliśmy kropek. No i przegapiliśmy okazję do tego, że mieliśmy bardzo pozytywny splot okoliczności, tylko nie umiemy go utrwalić w naszym zespole. Nie wyszło nam to w nowy nawyk, bo nie zauważyliśmy. I stąd tutaj taka uwaga. Te statystyki mogą być bardzo mocnym wsparciem, takim bardzo obiektywnym wsparciem, dla naszych subiektywnych przemyśleń, czy takich jakichś osobistych odczuć, które mogą nas niestety czasami sprowadzać na manowce. 

Jacek: Ostatnia przestroga, którą mamy na dzisiaj, to przestroga, która mówi o tym, żeby ostrożnie patrzeć na velocity jako na miarę efektywności. Ostrożnie, a tak mówiąc bardziej dosadnie, nie patrzeć na velocity jako miarę efektywności. Efektywności w rozumieniu takim, jaką faktycznie dostarczamy wartość. Bardzo łatwo jest popaść w takie złudzenie czy wiarę, że skoro velocity rośnie, no to możemy mówić o sukcesie zespołu. Natomiast tutaj obowiązuje ta zasada, że jakość tego, co zespół oddaje nam jako efekt pracy, bardzo mocno zależy od tego wsadu początkowego. Czyli tego, co mówiąc o Scrumie mamy w Backlogu Produktu, co prognozujemy sobie podczas planowania. No i jeżeli te elementy, na które się decydujemy, że chcemy je realizować to nie są te najwłaściwsze elementy, to nie są to najlepsze elementy, bądź są to tylko nasze domysły, na które nie mamy właściwie żadnego potwierdzenia, nie mamy żadnych badań, które by nam podnosiły pewność, że to są te właściwe rzeczy, które chcemy robić z perspektywy potrzeb naszych klientów. To nadal najwyższa prędkość, czy ciągle podnoszona prędkość, umożliwi nam w skrajnym przypadku szybkie dostarczanie niewłaściwych rzeczy czy niewłaściwych produktów. 

Kuba: I tutaj przychodzi mi do głowy taka metafora. Z nowoczesnego auta, na obecnie produkowanych autach na wyświetlaczu da się wyświetlić trochę statystyk na temat tego, jakim jesteśmy kierowcą. Ile przejechaliśmy kilometrów, ale też, jakie mamy właśnie na przykład średnie prędkości przejazdu od ostatniego zresetowania licznika. Ile jeszcze zostało kilometrów do najbliższego tankowania. No i tutaj prędkość w tej metaforze, to jest właśnie ta średnia prędkość przejazdu. Jak jadę wiele godzin po autostradzie, to ta średnia prędkość będzie wysoka. Jak jadę w korku po mieście, to ona będzie niższa. Tylko w sumie w gruncie rzeczy, to czy jadę szybko, czy jadę wolno, niespecjalnie mi mówi cokolwiek o efektywności mojej jazdy, rozumianej jako osiąganie tego efektu, czyli zmierzają do celu. Tutaj tych statystyk z tej metafory da się wyciągnąć o wiele więcej. Na przykład średnie spalanie, czyli jak wygląda strona kosztową naszej pracy, ale też czas potrzebny na dotarcie do celu. To już bardziej by nawigacja nam powiedziała, ile jeszcze godzin, czy ile jeszcze minut, żebyśmy dojechali do celu. I tutaj średnia prędkość niespecjalnie będzie miała ścisły związek z tym, ile jeszcze nam czasu na przejechanie do celu zostało. Bo może się okazać, że jedziemy zupełnie nie w tę stronę. Czyli szybsze jechanie w niewłaściwym kierunku nie przybliża nas do mety. I metafora nawigacji idzie jeszcze dalej. Jakby tego było za mało. Często, zwłaszcza jeśli jeździmy na takich nowoczesnych nawigacjach live, to w toku trasy okazuje się, że nawigacja na przykład podpowiada – dostępna jest szybsza trasa. Wielokrotnie jeżdżąc po Polsce, zdarzyło mi się, że nawigacja na przykład proponowała zjechać z autostrady, bo był korek na autostradzie. Pomimo że pierwotny plan zakładał, że to jest najlepsze, co mogę zrobić, to jechać dalej prosto, to nawigacja odkrywa, że warunki się zmieniły i trzeba skręcić. I rozsupłując tę metaforę na realia zespołów, jeśli nie mierzymy efektywności, nie zastanawiamy się, co nas przybliża do celu i nie konfrontujemy się z tym w miarę regularnie, no to niestety możemy szybko, zgodnie z pierwotnym planem, ładować się zupełnie nie w tym kierunku co trzeba. 

Kuba: I, żeby było tak pozytywnie, to porada co można zrobić zamiast? To wcale nie jest łatwe. Trzeba stworzyć i używać miary efektywności dla danego zespołu. Tutaj niestety zostaniemy trochę ogólnie, chociaż spróbujemy podać kilka przykładów, bo każdy zespół i każdy produkt tej miary efektywności prawdopodobnie będzie miał inny. Tak jak velocity może być tą miarą prędkości w miarę uniwersalną, tak miara efektywności pracy zespołu, miara dostarczonej wartości biznesowej, to jest coś, co jest dosyć unikalne dla danego produktu, dla danej branży i te mierniki będą trochę inne.

Jacek: Czasem to może być średnia wartość koszyka, czasem to może być przychód per klient. Czasem to może być czas onboardingu nowego klienta. Gdybyśmy budowali jakiś serwis odpowiadający za streaming, to być może średni czas, jaki użytkownik spędza konsumując nasze treści.

Kuba: Ale mogą być też miary takie mniej policzalne w gotówce, albo w jakichś czasach. To mogą być jakieś rzeczy związane z miarą na przykład bezpieczeństwa, jakie zapewnia nasz zespół. Miarą satysfakcji pracownika, jeśli to jest na przykład projekt jakiś wewnętrzny, związany z satysfakcją pracowników. Więc tutaj mnogość możliwych opcji jest duża. Ważne, żebyśmy my, w swoim własnym zespole zdefiniowali, co jest tą wartością biznesową. Jak ją będziemy mierzyli? Być może trzeba też stworzyć pewien mechanizm do tego, żeby te pomiary w ogóle były realizowane, żebyśmy nie tylko wiedzieli, co to jest, ale też faktycznie mieli świeże odczyty na temat tego, gdzie zmierzamy. 

Jacek: Podsumowując, jak sensownie możemy wykorzystać velocity? Przede wszystkim bazujmy na poprawnych danych i do statystyki liczmy tylko faktycznie skończone elementy.

Kuba: Używamy velocity do planowania krótkoterminowego i długoterminowego. Analizujmy wyniki velocity podczas Retrospektywy Sprintu i oprócz miary prędkości mierzymy też dostarczoną wartość biznesową.

Jacek: Velocity, o którym dzisiaj mówiliśmy, jest tylko jednym z przykładów praktyk zwinnych, które dosyć często są błędnie implementowane przez zespoły oraz firmy. Jeżeli Scrum w twoim zespole lub w twojej firmie nie przynosi takich efektów, jak się spodziewasz, to jest duża szansa, że wynika to z błędów implementacji tego frameworka.

Kuba: Pomagamy firmom zdiagnozować problemy i rekomendujemy sprawdzone sposoby, jak można je rozwiązać. Mamy dowody z rynku na to, że nasze eksperckie spojrzenie z zewnątrz przynosi wartość. Jeśli takie wsparcie, o jakim tutaj wspominamy, jest czymś, co jest potrzebne w twojej organizacji, skontaktuj się z nami przez formularz na stronie porzadnyagile.pl/kontakt.

 Jacek: Jak zawsze notatki do tego odcinka, transkrypcja, zapis wideo, a po kilku dniach również artykuł znajdziesz na stronie porzadnyagile.pl/75. I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. 

Jacek: I do usłyszenia wkrótce.