Często pytany jestem o to, jak wyliczać velocity Zespołu Scrum w sytuacji, gdy nie udało się ukończyć w Sprincie pracy nad wszystkimi podjętymi do realizacji elementami Backlogu Produktu. A nawet najlepszym Zespołom zdarzy się to od czasu do czasu. Odpowiedź zacznę od wyjaśnienia (albo przypomnienia) czym jest velocity i w jaki sposób odnosi się do tej miary definicja Scruma.

Velocity w Scrumie

Velocity to prędkość, z jaką Zespół jest w stanie realizować elementy Backlogu Produktu. Wyliczana jest jako suma oszacowań tych elementów, nad którymi praca została w pełni zakończona w określonym czasie. Oznacza to, że velocity dla rozważanego okresu wyliczane jest w takich samych jednostkach, w jakich wyrażane są estymaty elementów Backlogu ukończonych w tym czasie. Mogą to być popularne story pointy, ale równie dobrze Zespół może posługiwać się np. godzinami czy dniami roboczymi.

Wyliczanie prędkości w Scrumie nie jest obowiązkowe, podobnie jak nie jest obowiązkowe określanie wycen dla elementów Backlogu Produktu w żadnej formie. W szczególności Zespół może posługiwać się oszacowaniami w formie tekstowej (np. rozmiarami koszulek), symbolicznej (np. różnej wielkości owocami czy rasami psów). Może też nie przypisywać żadnych wycen (np. posługując się podejściem #NoEstimates).

Oznacza to, że o potrzebie wyliczania velocity samodzielnie zdecydować powinien Zespół. Jeśli uzna monitorowanie prędkości za przydatne, musi zadbać o wybór sposobu szacowania, który na to pozwoli, oraz dobrać przedział czasowy, dla którego kalkulacje będą sporządzane. W przypadku Zespołów Scrum jest to najczęściej po prostu długość Sprintu.

Nieukończona praca w Sprincie

Jeśli posługujemy się Scrumem i uda nam się zbudować nową wersję produktu, który spełnia wymogi Definicji Ukończenia, ta nowa wersja jest traktowana jako Przyrost. Przy czym w Scrumie nie jest wymagane stworzenie dokładnie jednego Przyrostu na Sprint – może, a wręcz powinno powstać ich wiele. Każdy z takich sekwencyjnie powstających Przyrostów zawiera w sobie wszystkie poprzednie. Inaczej mówiąc, z upływem czasu powstają kolejne Przyrosty i może się to dziać nawet wielokrotnie w ciągu jednego dnia.

Oczywiście w konkretnym momencie powstać może zawsze tylko jeden Przyrost. Jeśli równocześnie powstaną dwie nowe wersje tego samego produktu, które różnią się od siebie, to żadna z nich nie jest Przyrostem – ten powstanie wtedy, gdy z powodzeniem połączymy obie w działającą całość. Użytkownicy nie będą przecież posługiwać się dwoma wersjami produktu naraz, a wybierając jedną z nich, rezygnowaliby z funkcjonalności i możliwości tej drugiej.

Dla porządku dodam, że niektórzy błędnie utożsamiają Przyrost wyłącznie ze zmianami, jakich dokonali Developerzy w produkcie w ramach Sprintu. Nie jest tak – Przyrost to zarówno te zmiany, jak i wszystko, co wcześniej istniało w produkcie, o ile świadomie (właśnie w ramach zmiany) Developerzy czegoś z produktu nie usunęli. Inaczej mówiąc, nowa wersja produktu, która powstała poprzez usunięcie jakiejś cechy lub funkcjonalności, też będzie Przyrostem. Może się to wydawać mało intuicyjne, ale nazwa Przyrost w Scrumie odnosi się do przyrostu wartości oraz faktu, że jest on osiągany dzięki inkrementalnemu rozwojowi produktu. Nie chodzi więc o to, że produkt się powiększa, czyli że przyrasta liczba funkcji i cech, jakie posiada.

Czym zatem jest nieukończona praca w Sprincie? To praca, która nie doprowadziła do powstania Przyrostu.

Velocity a Przyrost w Scrumie

Poniżej dzielę się moim podejściem do tego, jak kalkulować velocity w różnych sytuacjach podczas pracy Zespołu w Sprintach. Opiera się ono na trzech kluczowych pytaniach, na które trzeba poszukać odpowiedzi.

Pytanie 1: czy powstał jakikolwiek Przyrost?

Jeśli w Sprincie nie powstał ani jeden Przyrost, velocity Zespołu wynosi dokładnie zero. Niczego bowiem nie udało się zrealizować.

Pytanie 2: jaki Przyrost wciąż istnieje, gdy Sprint się kończy?

Nieco bardziej skomplikowana jest sytuacja, gdy choć jeden Przyrost powstanie w czasie Sprintu. Wydawałoby się, że wystarczy po prostu ustalić, jakie elementy Backlogu Produktu zostały we wszystkich tych Przyrostach zrealizowane, a następnie zsumować ich oszacowania, aby ustalić wartość velocity, ale to nie takie proste.

Jeśli pod koniec Sprintu Zespół pracował nad jakimiś zmianami w produkcie, ale nie zdołał ich ukończyć, niezbędne jest sprawdzenie, które z Przyrostów wytworzonych w bieżącej iteracji wciąż istnieją. Jakim cudem mogą przestać istnieć po tym, jak już powstały? Tu kluczowa staje się kwestia nieukończonej pracy i jej wpływu na stan produktu w momencie zakończenia Sprintu.

W przypadku, gdy możliwe jest użycie najnowszego Przyrostu bez konieczności wykonania jakiegoś dodatkowego developmentu (wprowadzenia zmian w produkcie), velocity jest niezerowe i wylicza się go na podstawie oszacowań elementów Backlogu Produktu, których rozwiązania zawarte są tym Przyroście. Dlaczego tylko w tym ostatnim, a nie wszystkich, jakie powstały w trakcie bieżącego Sprintu? To proste: najnowszy Przyrost zawiera w sobie wszystkie poprzednie, ponieważ powstał jako ich ewolucyjne rozwinięcie.

Gdyby użycie najnowszego Przyrostu wymagało usunięcia niedokończonych zmian, nad którymi pracowali Developerzy pod koniec Sprintu, albo choćby sprawdzenia, że faktycznie wciąż jest w pełni ukończony (czyli przetestowania, czy wszystkie wymogi Definicji Ukończenia są nadal spełnione), w praktyce oznacza to, że najnowszy Przyrost przestał istnieć. Powstał w przeszłości, ale teraz wymagany jest development, by go odtworzyć. A ponieważ Sprint właśnie się kończy i pracę tę można wykonać dopiero w kolejnym, nie da się jej efektów wliczyć awansem do velocity iteracji bieżącej.

Zespołowi nie pozostaje wtedy nic innego, jak sięgnąć do wcześniejszego Przyrostu i powtórzyć sprawdzenie dla niego. A gdy i on nie jest już dostępny, do jeszcze starszego itd. Jeśli uda się znaleźć choć jeden Przyrost, który rzeczywiście może wciąż być użyty, to velocity wyliczyć należy na podstawie listy elementów Backlogu Produktu, które zostały w nim zrealizowane. W przypadku, gdy nie da się użyć żadnego z Przyrostów, jakie powstały w bieżącym Sprincie, velocity jest w tej iteracji zerowe.

Jak widać, skutki istnienia nieukończonej pracy na koniec Sprintu mogą być bolesne, dlatego tak ważne jest, by organizacja pracy Developerów ograniczała ryzyko, że do tego dojdzie.

Pytanie 3: które elementy Backlogu zostały skutecznie zrealizowane?

Przyjmijmy, że w Sprincie powstało po kolei kilka Przyrostów i albo nie ma żadnych nieukończonych zmian w produkcie, albo Developerzy zawczasu upewnili się, że nie powoduje to braku dostępności wcześniej wytworzonych funkcjonalności. Jakie wtedy jest velocity?

Należy sporządzić listę elementów Backlogu Produktu, których rozwiązania zawarte są w najnowszym Przyroście, jaki faktycznie istnieje, a które wytworzone zostały w bieżącym Sprincie. Prędkość Zespołu to suma oszacowań tych elementów. Nie ma potrzeby przeglądania zmian wprowadzonych we wcześniejszych Przyrostach, bo ten najnowszy z definicji zawiera je wszystkie.

Przy czym uwaga: do oceny, czy element Backlogu Produktu został zrealizowany, nie wystarczy sprawdzenie samej Definicji Ukończenia. Definicja ta zawiera bowiem jedynie kryteria jakości strukturalnej i determinuje, jak powinien być budowany produkt, by nadawał się do użytku. Nie oznacza to jednak automatycznie, że jest to właściwy produkt.

Możliwe są w związku z tym cztery różne scenariusze opisane poniżej.

Scenariusz 1: rozwiązanie zgodne z ustaleniami i właściwe

Jeśli interesariusze uznają, że zrealizowany element Backlogu doczekał się dobrego rozwiązania, wtedy oszacowanie tego elementu należy uwzględnić przy wyliczaniu velocity Zespołu. To najbardziej oczekiwany i typowy scenariusz.

Scenariusz 2: rozwiązanie zgodne z ustaleniami, ale niewłaściwe

Zdarza się, że Developerzy zrealizują element Backlogu zgodnie z ustaleniami, jakie poczynione zostały podczas pielęgnacji Backlogu Produktu i później w czasie Planowania Sprintu, a mimo to interesariusze uznają rozwiązanie za niewłaściwe. Nie dlatego, że Developerzy nie trzymali się ustaleń, ale dlatego, że dopiero po powstaniu działającego produktu możliwe stało się zrozumienie, jak chybione były pierwotne zamysły.

Oszacowanie takiego elementu należy wliczyć do velocity Zespołu. Owszem, rozwiązanie okazało się niewłaściwe, ale powstało i może zostać użyte i właśnie dzięki temu, że istnieje i można było poddać go walidacji, ujawniła się potrzeba zbudowania czegoś innego. Można powiedzieć, że pierwotny problem był źle zdefiniowany, dlatego jego rozwiązanie, choć zgodne z tą definicją, okazało się chybione. Dalsze zmiany stanowić będą zatem nowy problem do rozwiązania.

Dlatego Product Owner może potraktować taki element Backlogu Produktu jako zrealizowany i dalszą zmianę w produkcie opisać już za pomocą zupełnie nowego elementu. Może też umieścić oryginalny element na powrót w Backlogu, modyfikując go odpowiednio, a wtedy w kolejnym Sprincie (albo Sprintach późniejszych) zrealizowany zostanie po raz drugi, oczywiście już w inny sposób.

Scenariusz 3: rozwiązanie niezgodne z ustaleniami i niewłaściwe

Przyjmijmy, że Developerzy wytworzyli rozwiązanie, które ani nie jest zgodne z ustaleniami poczynionymi z Product Ownerem, ani nie rozwiązuje problemu opisanego w elemencie Backlogu Produktu. Oznacza to, że niewłaściwie zrealizowany element Backlogu Produktu powraca do Backlogu celem skorygowania jego rozwiązania. Nie powinien zostać uwzględniony przy kalkulacji velocity w kończącym się Sprincie, mimo że powstało rozwiązanie w pełni ukończone i spełniające wymogi Definicji Ukończenia.

Dlaczego tak i jaka jest różnica pomiędzy tą sytuacją a scenariuszem poprzednim? Czym innym jest odkrycie, że rozwiązanie zbudowane zgodnie z ustaleniami jest niewłaściwe, a czym innym dostarczenie rozwiązania niezgodnego z ustaleniami i jednocześnie bezwartościowego.

W pierwszym przypadku zmiany wprowadzone do produktu są zgodne z deklarowanymi potrzebami interesariuszy i doprowadzają do potrzeb tych doprecyzowania. Tak działa empiryczne odkrywanie, jaki produkt jest rzeczywiście potrzebny. W wyniku zakończonych prac pojawia się dodatkowa wiedza, która pozwala coś zrobić lepiej, a to wymierna wartość dla interesariuszy.

Drugi przypadek podsumować można tak: Zespół zmarnował czas na zrobienie czegoś, czego nikt nie oczekiwał, a jednocześnie wciąż nie wiadomo, czy rozwiązanie zgodne z ustaleniami byłoby właściwe. Jedyne, co wiadomo na pewno, to że wytworzone rozwiązanie wymaga przerobienia, co generuje dodatkowy koszt, którego dało się uniknąć. A pamiętajmy, że Zespół Scrum ma przede wszystkim dążyć do zaspokojenia potrzeb interesariuszy poprzez budowanie wartościowych rozwiązań, nie zaś „developować coś przez cały Sprint”.

Wyobraźmy sobie Zespół, który przez wiele miesięcy, Sprint po Sprincie, buduje rozwiązania niezgodne z ustaleniami i nierozwiązujące żadnego problemu interesariuszy. Jak można uznać, że velocity tego Zespołu w każdym z tych Sprintów jest niezerowe, skoro nie wytwarza niczego przydatnego dla interesariuszy, a wszystko, nad czym pracuje, powraca ciągle do Backlogu Produktu do ponownej realizacji?

Scenariusz 4: rozwiązanie niezgodne z ustaleniami, a jednak właściwe

Czy zawsze wytworzenie rozwiązania niezgodnego z ustaleniami skutkuje koniecznością jego zmiany i nieuwzględnieniem oszacowania elementu Backlogu Produktu w velocity? Nie, ponieważ działanie zwinne polega na odkrywaniu właściwych rozwiązań, a nie tylko na realizowaniu poczynionych wcześniej planów.

Wyobraźmy sobie, że Developerzy stworzyli Przyrost, w którym brak pewnych ustalonych cech, i w którym niektóre funkcjonalności działają inaczej, niż oczekiwali tego interesariusze. Jeśli taki produkt nie stanowi skutecznej odpowiedzi na potrzeby interesariuszy, mamy do czynienia z sytuacją opisaną w poprzednim scenariuszu (niewłaściwe rozwiązanie niezgodne z ustaleniami).

Jeśli jednak taki produkt mimo niezgodności z ustaleniami, okaże się wystarczający – bo rozwiązuje problemy interesariuszy i dostarcza im wartości – Product Owner może uznać, że niezależnie od wcześniejszych ustaleń, element Backlogu został skutecznie zrealizowany. Wtedy do velocity Zespołu jak najbardziej można dodać przypisane do tego elementu oszacowanie.

„Brak konsekwencji w opisie tych scenariuszy!”

Ktoś może mi zarzucić, że raz piszę, by uwzględniać przy wyliczeniu prędkości Zespołu oszacowania elementów Backlogu Produktu, które doczekały się rozwiązań nieadekwatnych z punktu widzenia interesariuszy, a potem, żeby absolutnie tego nie robić. Toż to sprzeczność!

No, niezupełnie.

Zajmijmy się najpierw scenariuszem trzecim i czwartym. Oba dotyczą sytuacji, w której Developerzy nie trzymają się ustaleń z pielęgnacji Backlogu Produktu i Planowania Sprintu. Mają prawo to robić, a nawet obowiązek, jeśli uznają, że tego wymaga uzyskanie wartości dla interesariuszy. Praca w Sprincie nie polega przecież na ślepym wykonywaniu statycznych planów.

Jeśli okaże się, że mimo odejścia od ustaleń powstało dobre rozwiązanie problemów interesariuszy, to znaczy, że element Backlogu Produktu z nim związany już do Backlogu nie powróci. Ciężko więc mówić, że nie nastąpiło przesunięcie w dół listy i że prędkość konsumowania elementów z niej jest wtedy zerowa.

Natomiast jeśli okaże się, że Developerzy ani nie zrobili tego, co było ustalone, ani nie rozwiązali problemów interesariuszy, velocity powinno być zerowe, bo problemy wciąż wymagają rozwiązania, a Backlog Produktu w żadnym stopniu nie został zmniejszony. Element, nad którym Zespół pracował, powróci przecież na listę jako rzecz do zrobienia.

Niższe lub wyższe velocity nie jest więc „karą za odejście od ustaleń”, ale po prostu miarą tempa rozwiązywania problemów. Lub prędkości konsumowania listy elementów z Backlogu Produktu, do czego nawiązuje nazwa techniki (velocity, czyli prędkość). Czasem decyzje podjęte w Sprincie przez Developerów okażą się dobre, czasem nie.

Uwaga: Product Owner nie musi umieścić na powrót w Backlogu Produktu elementu, który zrealizowany został niezgodnie z ustaleniami i w sposób sprzeczny z oczekiwaniami interesariuszy. Być może nie ma sensu dalej nad nim pracować, bo nawet jeśli powstanie lepsze rozwiązanie, stanie się to za późno, by miało jakąkolwiek wartość. W takim przypadku oszacowania tego elementu nadal nie należy wliczać do velocity Zespołu.

Gdyby ktoś bronił tezy, że przecież doszło do skonsumowania elementu z listy rzeczy do zrobienia, to proponuję eksperyment myślowy: jaka będzie, w myśl tej logiki, prędkość Zespołu, który niczego nie wytwarza, a jedynie usuwa z Backlogu Produktu dodane do niego elementy? Całkiem wysoka, co nie ma absolutnie żadnego sensu.

Wróćmy do scenariusza drugiego, czyli sytuacji, w której powstał Przyrost zgodny z oczekiwaniami, ale nieskutecznie rozwiązujący problemy interesariuszy. Dlaczego w mojej ocenie velocity miałoby być wtedy niezerowe?

Na dobrą sprawę mogłoby być zerowe i niektórzy faktycznie tak traktują tę sytuację. Dla mnie jednak stoi to w sprzeczności z ideą empirycznego odkrywania, jaki produkt jest potrzebny. Nigdy nie ma przecież pewności, że rozwiązanie, jakie zamierzamy zbudować, jest dobre, a często trzeba go wytworzyć, zanim zrozumiemy, że potrzebne jest co innego. To odkrycie (wiedza) jest wartością, którą zyskujemy dzięki wykonanej pracy. A skoro uzyskujemy wartość, velocity nie powinno być zerowe.

Jak to się ma do prędkości konsumowania elementów z Backlogu Produktu? Jeśli rozwiązanie wytworzone przez Zespół jest niewłaściwe i musi zostać przerobione, to wydaje się, że żadnego przesunięcia w dół listy nie będzie. Faktycznie, ale tylko jeśli posłużymy się kryterium ilościowym: potrzeba interesariuszy opisana była początkowo jednym elementem Backlogu i nadal jeden element z nią związany znajduje się na liście rzeczy do zrobienia. Inaczej wygląda to w ujęciu jakościowym: ten jeden element opisuje nowy problem, który został zdefiniowany na podstawie wniosków z prac, które zostały ukończone.

Kto i kiedy powinien wyliczyć velocity

Nie ma tu reguły, ale zwykle robi to wspólnie Zespół po zakończeniu Przeglądu Sprintu, np. w czasie Retrospekcji Sprintu.

Czy velocity da się wyliczyć przed Przeglądem? Zapewne tak, ale tylko wtedy, gdy nie jest do tego potrzebna dyskusja z interesariuszami. Oczywiście, jeśli brak Przyrostu, który nadawałby się do użycia, Przegląd nie zmieni w żaden sposób faktu, że velocity jest zerowe. Wtedy też bez trudu możemy go wyliczyć już przed Przeglądem.

Jeśli istnieje Przyrost, Product Owner może samodzielnie dokonać oceny tego, co zostało zrobione (niektórzy mówią, że dokonuje „odbioru” prac, ale w Scrumie tak naprawdę nie ma czegoś takiego – zachęcam do przeczytania wcześniejszego artykułu na ten temat). Rozsądniej będzie najpierw zebrać feedback od interesariuszy w ramach Przeglądu Sprintu. Dlaczego?

Wróćmy do czterech opisanych wcześniej scenariuszy: obejmują one ocenę rozwiązania zarówno pod kątem zgodności z ustaleniami (to Zespół może skutecznie zrobić bez interesariuszy), jak i ocenę jego adekwatności w odniesieniu do potrzeb opisanych elementami Backlogu Produktu (to mogą zrobić przede wszystkim interesariusze). Dlatego w większości przypadków o tym, jakie jest velocity w Sprincie, można powiedzieć dopiero w czasie Przeglądu albo po jego zakończeniu, gdy już wiadomo, co zostało ukończone z punktu widzenia interesariuszy.

Zdarza się, że obliczeniem velocity zajmuje się wyłącznie Product Owner i używa go do sporządzania różnych prognoz, a reszta Zespołu nie korzysta w żaden sposób z tej miary. Czy to poprawne? Sądzę, że tak, aczkolwiek zawsze lepiej, gdy Zespół robi to wspólnie. Skoro prędkość jest uznawana za coś użytecznego przez Product Ownera, dlaczego Developerzy i Scrum Master nie są zainteresowani jej wartością? A jeśli nie jest przydatna, czemu Product Owner ją wylicza i czy aby nie będzie prowadzić to do błędów decyzyjnych? Warto zadać sobie takie pytania.

Pragmatyzm a velocity

Mam świadomość, że niektórzy czytelnicy uznają proponowane podejście do kalkulacji velocity za nieracjonalne lub niepragmatyczne. Spieszę więc z wyjaśnieniem, dlaczego oskarżenia o brak realizmu lub pragmatyzmu są nieuzasadnione.

Scrum używany jest jako narzędzie do uzyskiwania wartości w środowisku o dużej złożoności i nieprzewidywalności. To oznacza, że niemal na pewno co jakiś czas (niewykluczone, że często) rozwiązanie zbudowane przez Developerów okaże się niewłaściwe. Iteracyjne i inkrementalne rozwijanie produktu ma spowodować, że korekty tego niewłaściwego rozwiązania dokonamy szybko – najlepiej już w kolejnym Sprincie. Dzięki temu rośnie szansa, że właściwe rozwiązanie zostanie wytworzone na moment, w którym jest potrzebne.

Velocity jest miarą tempa, w jakim Zespół przekształca Backlog Produktu na funkcjonalności i cechy produktu. Tym samym, jeśli Sprint nie rozwiązał żadnego problemu interesariuszy i nie spowodował, że niektóre elementy Backlogu Produktu można uznać za zrealizowane, velocity powinno być zerowe.

Zespół, który chce uniknąć takiej sytuacji, musi o to zadbać. Nie wystarczy skupić się wyłącznie na zrobieniu tego, co zapisane zostało w Backlogu Produktu, aby skutecznie zaspokajać potrzeby interesariuszy. I choć velocity nie jest miarą dostarczonej wartości, powinno być zerowe, jeśli żadnej wartości nie udało się wykreować.

Velocity nie jest też miarą tempa wykonywania pracy ani podstawą do oceny pracy Developerów. Dążenie do tego, by za wszelką cenę wykazać, że jest niezerowe, utrudnia użycie velocity do sporządzania prognoz tego, co i kiedy może zostać ukończone.

Współpraca zamiast formalizmów

Opisałem sposób wyliczania velocity, jakiego sam starałem się zawsze używać w Zespołach, z którymi współpracowałem. Wynika on z kilku prostych zasad:

  • Velocity powinno być zerowe, jeśli w wyniku wykonania prac nie powstał żaden Przyrost.
  • Powinno ono być zerowe również wtedy, jeśli prace nie przyniosły żadnej wartości interesariuszom, nawet jeśli powstał Przyrost.
  • Velocity może być niezerowe tylko wtedy, kiedy faktycznie udało się zrealizować elementy Backlogu Produktu i Zespół przesuwa się w dół listy rzeczy do zrobienia.
  • Velocity powinno być niezerowe, jeśli Sprint przyniósł wartość interesariuszom, nawet jeśli zapadnie decyzja o dalszej modyfikacji rozwiązań dopiero co wytworzonych w Sprincie.
  • Rozwiązanie może okazać się niewłaściwe już po jego wytworzeniu zgodnie z ustaleniami, co nie powinno obniżać velocity Zespołu.
  • Konieczność poprawiania wadliwego rozwiązania (np. usuwanie błędów) nie powinno podnosić velocity Zespołu.

Uwaga: poprawianie wadliwego rozwiązania to nie to samo, co przerabianie rozwiązania działającego, ale niezgodnego z oczekiwaniami. W pierwszym przypadku mamy do czynienia z produktem, który potencjalnie działa dobrze, ale został wytworzony w sposób, który uniemożliwia jego powtarzalne użycie. W drugim przypadku produktu da się użyć, ale działa on nie tak, jak chcą tego interesariusze. Usuwanie wad nie powinno podnosić velocity, natomiast dostosowanie produktu do potrzeb interesariuszy jak najbardziej – wszak przede wszystkim po to powstał Zespół.

Analizując cztery opisane przeze mnie scenariusze, bez trudu można dostrzec, jak kluczowa jest współpraca Product Ownera i Developerów w trakcie iteracji. Im ta współpraca jest lepsza i bardziej partnerska, im mniej formalizmów, im więcej elastyczności, tym większe prawdopodobieństwo, że na koniec Sprintu powstaną rozwiązania, które zaspokajają potrzeby interesariuszy. I to niezależnie od tego, co oryginalnie było zapisane w elementach Backlogu Produktu.

Podkreślam to, bo często widuję Zespoły, w których trwa nieustanna przepychanka między Product Ownerem i Developerami o to, czy poprawnie zinterpretowane zostały zapisy w Backlogu (np. kryteria akceptacji). Widuję też Zespoły, których celem jest „zrealizować wymagania zgodnie z tym, jak je zapisano”, a także Zespoły, w których toczy się walka o uzyskanie jak najwyższego velocity. To nie służy ani tym Zespołom, ani ich produktom, ani interesariuszom.

Zastosowanie poprawnie wyliczonego velocity

Velocity może być podstawą do sporządzania prognoz:

  • Product Owner może użyć wiedzy o prędkości Zespołu do przewidywania potencjalnych dat zakończenia realizacji poszczególnych elementów Backlogu Produktu.
  • Developerzy w czasie Planowania Sprintu mogą użyć velocity jako jednego z parametrów przy ocenie, co jest możliwe do zrealizowania przed końcem iteracji.

„Pompowanie w górę” velocity osłabi wartość prognoz, jakie na jego bazie zostaną sporządzone. Dlatego należy dążyć do tego, by realnie odzwierciedlało zdolność Zespołu do dostarczania wartościowych rozwiązań.

Moja propozycja sposobu wyliczania velocity nastawiona jest na uzyskanie takiego właśnie efektu: jeśli Zespół niezbyt radzi sobie z budowaniem wartościowego produktu, jego prędkość powinna być niska i stanowić sygnał, że konieczne są usprawnienia sposobu pracy.

Przy czym dotyczy to zarówno organizacji działań Developerów, jak i Product Ownera, przejrzystości Backlogu Produktu, relacji z interesariuszami itd., czyli wszystkiego, co może wpłynąć pozytywnie lub negatywnie na efektywność i skuteczność Zespołu.

Ciąg dalszy nastąpi

Pytań związanych z velocity i sytuacją, gdy w Sprincie nie udaje się ukończyć prac nad wszystkimi podjętymi do realizacji elementami Backlogu Produktu, jest więcej. Dlatego już wkrótce napiszę kolejny artykuł związany z tą tematyką. Podpowiem co robić z nieukończoną pracą i jak jej kontynuacja wpływa na prędkość w przyszłych Sprintach, a także czym posłużyć się zamiast velocity, jeśli nie chcemy lub z jakiegoś powodu nie możemy jej mierzyć.