Prędkość: do czego służy i jak ją obliczyć

Wskaźnik prędkości jest danymi wejściowymi do prognozowania, a nie wskaźnikiem KPI. W momencie, gdy zacznie się oceniać zespoły na podstawie tego wskaźnika, jego wartość ulega zawyżeniu.

Prędkość to średnia liczba punktów fabularnych, jaką zespół zrealizował w ciągu ostatnich kilku sprintów. To cała definicja. Służy ona wyłącznie jednemu celowi: prognozowaniu, ile sprintów zajmie zrealizowanie backlogu, biorąc pod uwagę rzeczywiste tempo realizacji zespołu. Należy zsumować pozostałe punkty, podzielić je przez prędkość, a otrzymamy prognozę. Szczerze mówiąc, to jedyna rzecz, do której służy.

Każde inne zastosowanie tego wskaźnika prowadzi do jego zniekształcenia. Pytanie „Dlaczego prędkość była niższa w tym sprincie?” sprawia, że każda retrospektywa zamienia się w obronę tej liczby. Stwierdzenie „Zespół A ma wyższą prędkość niż zespół B” traktuje niezależne kalibracje obu zespołów jako porównywalne, podczas gdy w rzeczywistości tak nie jest. Stwierdzenie: „W tym kwartale musimy zwiększyć prędkość o 20%” nakazuje zespołowi podwyższyć ten wskaźnik, a zespół to zrobi — poprzez zawyżanie szacunków dotyczących tej samej pracy, a nie poprzez wykonanie jej większej ilości. Prawo Goodharta w cyklu dwutygodniowym.

Jak to obliczyć

Proszę zsumować punkty uzyskane w każdym z ostatnich trzech do pięciu sprintów. Proszę obliczyć średnią. To właśnie jest Państwa prędkość. Proszę nie uwzględniać „wyjątkowych” sprintów — te właśnie stanowią część sygnału, który starają się Państwo wygładzić. Nie należy dwukrotnie uwzględniać zadań przeniesionych z poprzedniego sprintu. Nie należy w ogóle uwzględniać częściowo ukończonych zadań; są one uwzględniane w tym sprincie, w którym faktycznie zostały ukończone. Im prostsze obliczenia, tym trudniej je manipulować.

Prędkość ustabilizuje się po tym, jak zespół przepracuje razem trzy lub cztery sprinty. Nowy zespół, nowa historia referencyjna, poważna zmiana personalna — to wszystko powody, by odrzucić poprzednią wartość i zacząć od nowa. Ta wartość nie jest właściwością samej techniki; jest właściwością tego zespołu w tym konkretnym okresie. Zespół, który wczoraj stracił dwóch członków, ma wczorajszą prędkość charakterystyczną dla innego zespołu.

Ile punktów fabularnych przypada na jeden sprint?

Wyszukiwanie hasła „ile punktów fabularnych na sprint” stanowi błąd kategoryczny. Nie ma żadnej branżowej wartości odniesienia, żadnej „dobrej” liczby, ani wskaźnika na programistę na dzień. Prędkość (velocity) to zmierzona wydajność zespołu, a jedyną użyteczną wartością jest średnia krocząca z kilku ostatnich sprintów danego zespołu. Piętnaście punktów, czterdzieści punktów, sto punktów — żadna z tych wartości nie jest ani prawidłowa, ani błędna. Są one skalibrowane względem historii referencyjnej zespołu.

Warto więc wykorzystać prędkość do trzech celów i tylko do tych trzech: oszacowania terminu realizacji dla znanego zakresu prac (zakres ÷ prędkość = liczba sprintów); zdecydować, co zmieści się w następnym sprincie (wybierać zadania, aż ich suma wyniesie około 80–90% ostatniej średniej, pozostawiając miejsce na zadania nieplanowane); oraz zauważyć, kiedy coś się zmieniło (spadek o 30% to sygnał wart omówienia podczas retrospektywy). Czego nie można robić: porównywać jej z wynikami innego zespołu, wykorzystywać jej do oceniania zespołu ani przeliczać jej na „przewidywane godziny pracy na programistę dziennie”. Każde z tych działań stanowi ten sam błąd, tylko w innym przebraniu.

Co idzie nie tak

Najczęstszy sposób, w jaki dochodzi do niepowodzenia: menedżer interpretuje wartość prędkości jako „jak produktywny jest ten zespół?”. Wartość ta jest przytaczana podczas spotkań dotyczących stanu realizacji, a następnie porównywana między zespołami i staje się celem do osiągnięcia. W ciągu dwóch sprintów zespół dostosowuje swoje szacunki wielkości zadań, aby wskaźnik wzrósł — każda historia ma teraz o 30% większą wielkość niż dotychczas — a wskaźnik prędkości przestał oznaczać to, co wcześniej. Prognoza, którą miał on zapewnić, jest teraz błędna.

Po drugie: porównywanie zespołów. Dwa zespoły oceniające ten sam backlog uzyskują różne wartości prędkości, ponieważ posługują się różnymi historiami odniesienia — na tym właśnie polega istota szacowania względnego. Porównywanie ich przypomina porównywanie dwóch termometrów o różnych punktach zerowych. Liczby te nie mają tego samego znaczenia, a traktowanie ich tak, jakby miały, zaburza kalibrację obu zespołów.

Kiedy należy dokonać ponownej wyceny

Ponowne oszacowanie już wykonanej pracy spowalnia tempo realizacji. Jedynym uczciwym przypadkiem jest ponowne oszacowanie pracy przeniesionej z poprzedniego okresu.

Co kwartał pojawia się pytanie: „Oceniliśmy to na 5, a w rzeczywistości było to 13 — czy powinniśmy to zaktualizować?”. Instynkt podpowiadający, że tak, to ten sam instynkt, który domaga się, by każda liczba była z mocą wsteczną poprawna, a jest to błędne podejście. Prędkość to tempo, w jakim zespół — przy kalibracji, jaką posiadał w tamtym momencie — wykonał pracę. Cofnięcie się i zmiana punktacji powoduje również zmianę kalibracji, a prognoza, która wcześniej działała, przestaje być miarodajna. Stwierdzenie: „Zespół przyspieszył, więc stare zadania powinny być mniejsze” usuwa jedyny sygnał wskazujący, że zespół się poprawił. „Ta ocena 5 okazała się być 13” stanowi sygnał do doprecyzowania oceny kolejnego podobnego zadania, a nie uprawnienie do zmiany historii tego konkretnego zadania.

Jedynym przypadkiem, w którym należy dokonać ponownej wyceny, jest przeniesienie zadań. Zadanie nie zostało ukończone, sprint dobiega końca, a pozostała praca zostaje przeniesiona do zakresu prac następnego sprintu. Ta pozostała praca znacznie różni się od tego, co oszacowano na początku — zespół wykonał jej część, napotkał co najmniej jedną nieznaną przeszkodę i ma teraz jaśniejszy obraz tego, co pozostało do zrobienia. Proszę ponownie poddać ją głosowaniu tak, jakby była nowym zadaniem, traktując pierwotny szacunek raczej jako punkt odniesienia niż ograniczenie.

Ujednolicenie prędkości w poszczególnych zespołach

Normalizacja jest przede wszystkim rytuałem w ramach SAFe, mającym na celu zapewnienie spójności danych na pulpicie nawigacyjnym portfela. Proszę się temu sprzeciwić, chyba że ktoś z Państwa przełożonych rzeczywiście potrzebuje tego pulpitu nawigacyjnego.

Normalizacja polega na uzgodnieniu przez co najmniej dwa zespoły wspólnej wartości odniesienia — zazwyczaj jest to coś w rodzaju „jednego dnia pracy przeciętnego inżyniera” — dzięki czemu ocena 5 w zespole A oznacza to samo, co ocena 5 w zespole B, a prędkości obu zespołów można zsumować. Technika ta działa: znormalizowana ocena 5 rzeczywiście oznacza to samo we wszystkich zespołach, które się na nią zgodziły. Problem polega na tym, czym ją pan/pani zapłacił(a). Wymienili Państwo właściwość względnego szacowania każdego zespołu na właściwość bezwzględną — co jest szacowaniem czasu trwania w przebraniu — wyłącznie po to, aby można było uśrednić liczbę między zespołami, które nie dzielą wspólnej bazy kodu, stosu technologicznego ani dziedziny.

Jeśli prognoza na poziomie portfela rzeczywiście służy finansowaniu prac (a nie tylko porównywaniu zespołów), należy przeprowadzić normalizację na poziomie agregacji: kierownictwo programu powinno ustalić mnożnik punktowy dla każdego zespołu – skalibrowany jednorazowo i rzadko weryfikowany – i stosować go podczas agregacji danych. Każdy zespół nadal dokonuje szacunków w oparciu o własną historię referencyjną; mnożnik przekształca prędkość zespołu na walutę portfela, a podczas spotkań poświęconych dopracowywaniu szacunków nigdy nie jest on uwzględniany. Czego należy unikać: normalizacji rozpoczynającej się w obrębie pojedynczego zespołu oraz normalizacji przeprowadzanej wyłącznie w celu ułatwienia porównywania zespołów. Ten drugi przypadek nie jest właściwym zastosowaniem — jest to antywzorzec pod elegancką nazwą.

Narzędzia programistyczne Velocity i AI

Copilot, Cursor, Claude Code. Punkty pozostają niezmienne. Zmienia się prędkość — i to dopiero po fakcie.

W każdym zespole, który korzysta z asystenta programistycznego opartego na sztucznej inteligencji od kilku miesięcy, pojawia się to samo pytanie: wprowadzamy zmiany na rynek szybciej, czy powinniśmy zatem skorygować wielkość zaległości? Czy wartość 3 z poprzedniego kwartału powinna w tym kwartale wynosić 5? Odpowiedź brzmi: nie, ponieważ punkty fabularne nigdy nie mierzyły tego, co uległo zmianie. Punkty mierzą względną złożoność i niepewność; asystent skraca czas poświęcany na pisanie kodu dla danego zadania, czasami w sposób znaczący, ale złożoność pozostaje niezmieniona, niewiadome pozostają niezmienione, ryzyko integracji i przypadki skrajne pozostają niezmienione. Nie należy zmieniać oceny z 5 na 3 tylko dlatego, że narzędzie napisało standardowy kod, a Państwo ponownie szacują nakład pracy w godzinach.

To, co się zmienia, to tempo pracy. Ten sam zespół, dostarczający ten sam rodzaj pracy z pomocą asystenta, generuje więcej punktów na sprint niż sześć miesięcy temu — nie dlatego, że punkty stały się mniejsze, ale dlatego, że zespół szybciej przekształca punkty w gotowy kod. To właśnie ta liczba spełnia swoje zadanie i naturalnie dostosowuje się w ciągu trzech lub czterech sprintów. Należy dbać o to, by referencyjna historia zespołu była aktualna — taka, którą zrealizowano przy użyciu narzędzi, z których korzysta obecnie — a kalibracja uwzględnia już wszelkie istniejące przyspieszenia.

Należy zwrócić uwagę na dwie kwestie. Stwierdzenie „Prędkość wzrosła o 30%, postarajmy się osiągnąć wzrost o kolejne 30%” oznacza podwójne uwzględnienie tej poprawy: ostatnia średnia uwzględnia już wpływ sztucznej inteligencji, więc nie należy jej ponownie skalować. „Wszystko stało się mniejsze, więc ponownie oszacujmy zaległości” to wspomniana powyżej pułapka ponownego szacowania — zadania nie stały się mniejsze, zespół stał się szybszy, a prognoza już to odzwierciedla. Niepewność to obszar, w którym narzędzia pomagają najmniej: asystent przyspiesza niektóre etapy badania spike’a, ale przedmiot, który spike próbuje zbadać, nie stał się wcale mniejszy.

Najczęściej zadawane pytania

Ile punktów fabularnych na sprint jest normą?

Nie ma jednej uniwersalnej wartości dla całej branży. Prędkość to zmierzona przepustowość Państwa zespołu — średnia krocząca liczby punktów zrealizowanych w ciągu ostatnich kilku sprintów. Piętnaście, czterdzieści, sto: żadna z tych wartości nie jest właściwa ani niewłaściwa, ponieważ każda z nich jest dostosowana do innego scenariusza odniesienia.

Ile punktów fabularnych przypada na jednego programistę w ramach jednego sprintu?

Proszę tego nie obliczać. Stawka na jednego programistę sprawia, że punkty fabularne ponownie stają się ukrytymi godzinami pracy i zachęca do porównań między poszczególnymi osobami, czego ta technika ma właśnie uniknąć. Prędkość jest wartością zespołową, a nie sumą indywidualnych limitów.

Ile punktów fabularnych obejmuje dwutygodniowy sprint?

Niezależnie od tego, ile zadań Państwa zespół zrealizował dotychczas w ramach dwutygodniowego sprintu — proszę to zmierzyć, ale nie wyznaczajcie tego jako celu. Wybierajcie zadania tak, aby ich łączna liczba wynosiła około 80–90% Państwa ostatniej średniej, i pozostawcie miejsce na zadania nieplanowane.

Jaka jest odpowiednia prędkość pracy dla zespołu pracującego w metodologii Scrum?

Stabilna. „Czy nasze tempo jest dobre?” – to pytanie, które powoduje załamanie systemu — w momencie, gdy tempo podlega ocenie, wyniki sztucznie rosną, a w rzeczywistości nic nie trafia do klienta szybciej. Dobre tempo to takie, na podstawie którego można planować, a nie liczba, która nieustannie rośnie.

Warto przeczytać

• Punkty fabularne a godziny — dlaczego przeliczanie punktów na godziny stanowi ten sam rodzaj błędu, który eliminuje wskaźnik prędkości.
• Planowanie prędkości i wydajności — wykorzystanie prędkości do określenia realistycznego zakresu zadań w sprincie.
• Czym jest wykres burndown? — w jaki sposób zespoły śledzą realizację punktów, do których się zobowiązały w ramach sprintu.
• Przewodnik po szacowaniu w metodologii agile — kompletny zestaw materiałów dotyczących szacowania.
• Bezpłatny Planning Poker dla zespołów stosujących metodologię agile — oszacuj liczbę punktów, z których oblicza się wskaźnik prędkości (velocity).