Wskaźnik wydajności zespołu w metodologii agile: jak go mierzyć i wykorzystywać (+ bezpłatny kalkulator)

Wskaźnik Team Velocity stanowi dane wejściowe do prognozowania, a nie wskaźnik 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ół realizuje w ciągu jednego sprintu, obliczona na podstawie ostatnich kilku sprintów. To cała definicja. Służy ona wyłącznie jednemu celowi: oszacowaniu, 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 otrzymają Państwo prognozę. To jedyna rzecz, do której faktycznie służy.

Każde inne zastosowanie tej miary prowadzi do jej 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ć wskaźnik velocity o 20%” nakazuje zespołowi podwyższenie tego wskaźnika, a zespół to zrobi, zawyżając szacunki dotyczące tej samej pracy, zamiast wykonać jej więcej. Jest to prawo Goodharta działające w cyklu dwutygodniowym.

Zanim przejdziemy do instrukcji, jedna szczera uwaga: Przewodnik po Scrumie nie wspomina o wskaźniku prędkości. Jest to powszechna praktyka stosowana jako uzupełnienie metodyki Scrum, a nie jej zasada, i właśnie dlatego warto świadomie rozważyć, do jakich celów ją Państwo wykorzystują.

Jak obliczyć prędkość zespołu

Proszę zsumować punkty zdobyte w każdym z ostatnich trzech do pięciu sprintów. Proszę obliczyć średnią. To właśnie jest Państwa prędkość.

Przykład z praktyki, obejmujący trzy sprinty:

Sprint	Zrealizowane punkty fabularne
Sprint 7	21
Sprint 8	34
Sprint 9	26

Prędkość = (21 + 34 + 26) podzielone przez 3 = 27 punktów na sprint.

Jeśli w zaległościach pozostało 210 punktów, prognoza wynosi 210 podzielone przez 27, co daje około 8 sprintów. Ponieważ wartości wejściowe mieściły się w przedziale od 21 do 34, rzetelna odpowiedź brzmi „od siedmiu do dziesięciu sprintów”, a nie „7,8 sprintu”. Można też pominąć obliczenia i zlecić ich wykonanie powyższemu kalkulatorowi.

Zasady zapewniające rzetelność danych: nie należy korygować wyników z uwzględnieniem „wyjątkowych” sprintów, ponieważ właśnie te wyjątkowe sprinty stanowią część sygnału, który starają się Państwo wygładzić. Nie należy dwukrotnie uwzględniać prac przeniesionych z poprzedniego sprintu, a także w ogóle nie należy uwzględniać częściowo ukończonych zadań. Zadania te uwzględnia się w tym sprincie, w którym faktycznie zostały ukończone. Im prostsze obliczenia, tym trudniej je manipulować.

Tempo ustabilizuje się po tym, jak zespół przepracuje razem trzy lub cztery sprinty. Powstanie nowego zespołu, nowa historia referencyjna lub znacząca zmiana personalna to powody, dla których należy odrzucić poprzednią wartość i rozpocząć od nowa. Wartość ta nie jest cechą charakterystyczną samej techniki. Jest to cecha charakterystyczna tego konkretnego zespołu w danym okresie. Zespół, który wczoraj stracił dwóch członków, ma wskaźnik prędkości z wczoraj, który odnosi się do innego zespołu.

Wykorzystanie wskaźnika prędkości do planowania kolejnego sprintu

Metoda Velocity sprawdza się w planowaniu sprintów, a jej opis jest zwięzły:

1. Proszę opierać się na średniej kroczącej z ostatnich trzech do pięciu sprintów, nigdy na wyniku pojedynczego sprintu, a już na pewno nie na swoim najlepszym sprincie.
2. Proszę uwzględnić znane zmiany w zasobach. Dwie osoby na urlopie w następnym sprintzie? Dzień wolny od pracy? Proszę proporcjonalnie zmniejszyć cel przed rozpoczęciem planowania, a nie z wyrazami skruchy już po fakcie. Wskaźnik prędkości odnosi się do zespołu, który go osiągnął, a zespół w następnym sprintzie bywa mniejszy.
3. Zarezerwujcie mniej niż średnią – około 80–90 procent tej wartości. Wybierajcie zadania tak, aby ich łączna wartość wynosiła mniej więcej tyle, a pozostałą rezerwę przeznaczcie na nieplanowane prace, które pojawiają się w każdym sprincie, niezależnie od tego, czy je zaplanowaliście, czy nie.
4. Proszę podawać prognozy w przedziałach. W przypadku zadań wykraczających poza następny sprint proszę podać jako granice najlepszy i najgorszy wynik z ostatnich sprintów. Interesariusze mogą planować w oparciu o przedział „od siedmiu do dziesięciu sprintów”. Nie mogą natomiast opierać się na konkretnej liczbie, która może okazać się błędna.

Wykorzystujcie wskaźnik prędkości do trzech celów i tylko do tych trzech: prognozowania terminu realizacji dla znanego zakresu prac (zakres podzielony przez wskaźnik prędkości daje liczbę sprintów), ustalania, co zmieści się w następnym sprincie, oraz wykrywania zmian (spadek o 30 procent stanowi sygnał, który warto omówić podczas retrospektywy). Czego nie wolno 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 wydaniu.

Ile punktów fabularnych przypada na jeden sprint?

Wyszukiwanie hasła „ile punktów fabularnych na sprint” stanowi błąd kategoryzacji. Nie ma żadnej branżowej wartości odniesienia, żadnej „dobrej” liczby ani wskaźnika wydajności na programistę na dzień. Prędkość (velocity) to zmierzona przepustowość 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.

Poważny błąd: prędkość jako wskaźnik wydajności

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ół zrewidował swoje szacunki wielkości zadań, aby wynik ten 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, które szacują tę samą liczbę zadań w backlogu, uzyskują różne wartości prędkości, ponieważ wykorzystują różne historie referencyjne – i 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.

Chcieliby Państwo, aby ktoś wykonał za Państwa obliczenia? Proszę wrócić do bezpłatnego kalkulatora prędkości i wprowadzić w nim dane dotyczące Państwa własnych sprintó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ść (velocity) to tempo, w jakim zespół, przy kalibracji, jaką posiadał w danym 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ół stał się szybszy, 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 oceny, 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 pierwotną wycenę raczej jako punkt odniesienia niż ograniczenie.

Ujednolicenie tempa pracy 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ólnego punktu odniesienia, zazwyczaj w postaci „jednego dnia roboczego 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). Zamienili 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: niech kierownictwo programu ustali mnożnik punktowy dla każdego zespołu – skalibrowany jednorazowo i rzadko weryfikowany – i stosuje go podczas agregacji danych. Każdy zespół nadal dokonuje szacunków w odniesieniu do własnego zadania referencyjnego; mnożnik przekształca prędkość zespołu na jednostkę miary portfela, a uczestnicy spotkań dotyczących dopracowywania zadań nigdy nie mają z nim styczności. 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, lecz antywzorem 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 od kilku miesięcy korzysta z asystenta programistycznego opartego na sztucznej inteligencji, pojawia się to samo pytanie: skoro dostarczamy oprogramowanie szybciej, czy powinniśmy 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 w ramach danego zadania, czasami w sposób znaczący, ale złożoność pozostaje niezmieniona, niewiadome pozostają niezmienione, ryzyko integracji i przypadki skrajne pozostają niezmienione. Zmiana oceny z 5 na 3 tylko dlatego, że narzędzie napisało standardowy kod, a Państwo ponownie szacują nakład pracy w godzinach, jest błędem.

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 swoją rolę i naturalnie się aktualizuje w ciągu trzech lub czterech sprintów. Proszę zadbać 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%” powoduje podwójne uwzględnienie poprawy: ostatnia średnia uwzględnia już wpływ sztucznej inteligencji, więc nie należy jej ponownie skalować. Stwierdzenie: „Wszystko stało się mniejsze, więc ponownie oszacujmy zaległości” stanowi wspomnianą powyżej pułapkę ponownego szacowania: zadania nie uległy zmniejszeniu, to 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 ma na celu zbadać, nie stał się wcale mniejszy.

Wspólne ustalanie szacunków w TeamRetro

Skuteczność metody Velocity zależy od jakości szacunków, na których się opiera. Aplikacja TeamRetro Estimations umożliwia przeprowadzenie gry w „planning poker” z Państwa zespołem – zarówno w trybie na żywo, jak i asynchronicznym – dzięki czemu punkty wprowadzane do tego kalkulatora wynikają z oceny całego zespołu, a nie z przypuszczeń jednej osoby. Wypróbuj TeamRetro Estimations lub zacznij od bezpłatnego narzędzia do pokera planistycznego.

Najczęściej zadawane pytania

Czym jest prędkość zespołu w metodologii agile?

Współczynnik wydajności zespołu to średnia liczba punktów fabularnych, które zespół realizuje w ciągu jednego sprintu; zazwyczaj mierzy się go na podstawie ostatnich trzech do pięciu sprintów. Stanowi on dane wejściowe do planowania, wykorzystywane do prognozowania, ile zadań zmieści się w następnym sprincie oraz ile czasu zajmie realizacja zaległości, a nie jest miarą jakości pracy zespołu.

W jaki sposób oblicza się prędkość zespołu?

Proszę zsumować punkty za zadania zrealizowane w każdym z ostatnich trzech do pięciu sprintów i obliczyć średnią. Jeśli w ostatnich trzech sprintach zrealizowano odpowiednio 21, 34 i 26 punktów, wówczas prędkość wynosi 27. Proszę uwzględniać wyłącznie zadania zakończone w danym sprincie, w którym zostały zrealizowane, lub skorzystać z bezpłatnego kalkulatora dostępnego na tej stronie, aby obliczyć wyniki.

Jaka jest odpowiednia prędkość pracy zespołu?

Stabilna. Nie ma tu punktu odniesienia, ponieważ punkty każdego zespołu są dostosowane do jego własnego scenariusza referencyjnego, więc wartości 15, 40 i 100 mogą być równie dobre. Dobra prędkość to taka, na podstawie której można planować, a nie liczba, która nieustannie rośnie.

Czy należy porównywać tempo pracy poszczególnych zespołów?

Nie. Poszczególne zespoły kalibrują punkty w odniesieniu do różnych scenariuszy referencyjnych, więc ich prędkości nie są wyrażone w tych samych jednostkach. Porównywanie ich przypomina porównywanie dwóch termometrów o różnych punktach zerowych. Porównania między zespołami wywierają również presję na zespoły, by zawyżały szacunki, co zniekształca prognozy, do których sporządzenia służy wskaźnik prędkości.

A co, jeśli nie będziemy szacować w punktach, tylko na przykład w rozmiarach koszulek?

Nadal można śledzić przybliżoną przepustowość, ale nie da się uzyskać rzeczywistej wartości prędkości bezpośrednio na podstawie rozmiarów koszulek, ponieważ rozmiary te nie sumują się. Istnieją dwie możliwości. Najpierw należy przyporządkować rozmiary do prostej skali punktowej (na przykład XS = 1, S = 2, M = 3, L = 5, XL = 8), zsumować liczbę ukończonych elementów w każdym sprintie, a wynik traktować jako ogólną tendencję, a nie precyzyjną wartość. Lub, jeśli Państwa zadania mają zazwyczaj podobną wielkość, proszę zamiast tego liczyć przepustowość: liczbę zadań ukończonych w każdym sprincie. Oba podejścia są mniej precyzyjne niż prędkość oparta na punktach, dlatego należy je traktować jako wskazówki kierunkowe, a nie wartości dziesiętne. Gdy potrzebna jest rzeczywista prognoza, proszę ponownie oszacować pracę w najbliższym czasie w punktach. Zapoznaj się z naszym przewodnikiem dotyczącym rozmiarów koszulek, aby poznać przelicznik rozmiarów na punkty.

W jaki sposób należy rozliczać prace, które nie są ewidencjonowane jako pozycje o określonej wielkości?

Wskaźnik prędkości odzwierciedla wyłącznie pracę, którą faktycznie szacują Państwo i monitorują. Zgłoszenia do pomocy technicznej, spotkania, przerwy w pracy oraz nieokreślone naprawy błędów nadal pochłaniają zasoby, więc jeśli znaczna część tej pracy pozostaje niewidoczna, Państwa wskaźnik prędkości będzie wydawał się niższy niż rzeczywisty nakład pracy zespołu, a Państwa prognozy okażą się zbyt optymistyczne. Dwa skuteczne rozwiązania. Proszę rejestrować powtarzające się, nieplanowane zadania jako pozycje z oszacowanym nakładem pracy, tak aby były uwzględniane w wskaźniku prędkości tak samo jak wszystkie inne zadania. Można też otwarcie zarezerwować na nie część zasobów, angażując około 80–90 procent średniej wydajności, a resztę pozostawiając jako rezerwę. Proszę nie przypisywać punktów do niewidocznych zadań tylko po to, by liczba wyglądała na większą, ponieważ zaburza to kalibrację, od której zależy wskaźnik prędkości.

W jaki sposób uwzględnia się prace poprawkowe w wskaźniku prędkości?

Praca poprawkowa wymaga rzeczywistego wysiłku, jednak ponowne uwzględnienie zadania, które zostało już zaliczone jako zrealizowane, zaburza wskaźnik prędkości. Proszę traktować pracę poprawkową jak nową pracę: proszę utworzyć nową pozycję, oszacować jej wielkość i zaliczyć ją w sprincie, w którym zostanie ukończona. Nie należy ponownie otwierać pierwotnego zadania ani dokonywać jego ponownej wyceny. Jeśli konieczność ponownej pracy pojawia się regularnie, jest to sygnał dotyczący jakości, który warto omówić podczas retrospektywy, a nie pretekst do korekty wskaźnika prędkości. Prognoza pozostaje rzetelna tylko wtedy, gdy każdy punkt jest liczony jednokrotnie, w sprincie, w którym praca została faktycznie zakończona.

Ile punktów fabularnych na sprint jest standardem?

Nie ma jednej uniwersalnej wartości dla całej branży. Prędkość to zmierzona przepustowość Państwa zespołu, czyli ś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ę nie obliczać tego w ten sposób. 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 traktować jako celu. Proszę wybierać zadania tak, aby ich łączna wartość wynosiła około 80–90 procent Państwa ostatniej średniej, i pozostawić miejsce na zadania nieplanowane.

Jaka prędkość realizacji jest odpowiednia 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 są zawyżane, a w rzeczywistości nic nie jest dostarczane szybciej. Dobre tempo to takie, na podstawie którego można planować, a nie liczba, która nieustannie rośnie.

Materiały powiązane

• Punkty fabularne a godziny: dlaczego przeliczanie punktów na godziny stanowi źródło błędów, które eliminuje wskaźnik prędkości.
• Planowanie prędkości i wydajności: wykorzystanie prędkości do określenia realistycznego zakresu prac w ramach sprintu.
• Czym jest wykres burndown?: w jaki sposób zespoły śledzą realizację punktów, do których się zobowiązały w ramach sprintu.
• Techniki szacowania w metodologii agile: gdzie w tym kontekście plasuje się wskaźnik prędkości (velocity) wśród takich metod jak planning poker, punkty fabularne i inne, oraz kiedy należy stosować poszczególne z nich.
• Przewodnik po szacowaniu metodą agile: kompletny zestaw informacji dotyczących szacowania.
• Bezpłatny Planning Poker dla zespołów stosujących metodologię agile: oszacuj liczbę punktów, na podstawie których oblicza się prędkość.