Dwa tematy za jednym razem, czyli wyjaśniamy pojęcia capacity oraz velocity. Szczególnie w kontekście Scruma ale i nie tylko. Co więc jest z tym Velocity i Capacity?
Czym jest velocity?
Velocity, to miara, która mówi o tym, ile zespołowi udaje się zrealizować wymagań w jakiejś jednostce czasu. Velocity opisuje więc średnią „prędkość” zespołu wyrażoną w jakiejkolwiek wartości liczbowej. Ponieważ najczęściej używaną miarą przez Zespoły Scrumowe są Story Points, to najczęstszą jednostką Velocity są „Story Points na Sprint”. Znaczy to, że jeśli jakiś zespół przez ostatnie 5 Sprintów zrealizował 170 Story Pointów w ukończonych zgodnie z Definition of Done wymaganaich, to Velocity wyniesie 34 Story Pointy na Sprint.
I tu zaczynają się schody. Niektóre zespoły wybierają wartość średnią, a inne – maksymalną. Ta druga opcja zdecydowanie nie jest polecana. Najbardziej popularne jest liczenie Velocity za ostatnie trzy do pięciu Sprintów, jako średnia krocząca. Sposób naszej pracy ewoluuje i to co było średnią prędkością 15 Sprintów temu, niekoniecznie musi przestawać do dzisiejszych warunków.
Tu warto dodać też słowo komentarza, że niektóre zespoły w ogóle nie szacują swoich wymagań. Velocity wtedy określa liczbę zrealizowanych Elementów Backlogu Produktu na Sprint. W takim przypadku powiemy na przykład, że dany zespół jest w stanie zrobić średnio 6 wymagań w każdej iteracji.
Oczywiście, jeżeli szacujemy w miarach bezwzględnych jak na przykład w godzinach to w ogóle nie ma co liczyć naszego Velocity. Wtedy wynika ono wprost ze składu zespołu. Np. dwa tygodnie pracy 10 osób po 8 godzin dziennie to… zawsze ta sama liczba. Trudno jest wymyślić tu coś innego.
A co z Capacity?
Capacity to pojemność zespołu, czyli przewidywana wielkość zrealizowanych wymagań w najbliższym Sprincie czy iteracji. Oczywiście jest to wartość wyrażona w tej samej mierze, której używamy do wyliczania Velocity. Czyli, jeżeli używamy Story Pointów to są to Story Pointów, a jeżeli używamy liczby wymagań, to jest to liczba wymagań. W odróżnieniu od Velocity, Capacity możemy wyliczyć też godzinowo, jako „dostępność naszego zespołu”. Wyrażona w godzinach lub w procentach powie nam o planowanych urlopach i niedostępnościach.
W standardowym, niczym nie wyróżniającym się Sprincie, Capacity równa się zwykle średniemu Velocity. Przecież tyle średnio robimy co Sprint! Natomiast w sytuacjach „problematycznych”, jak np. świąteczny Sprint, urlopy i tak dalej, wartość ta może być znacząco różna.
Niektóre zespoły próbują wyliczać Capacity w sposób matematyczny, natomiast doświadczone i zgrane zespoły robią to po prostu „na czuja”. Patrząc na zaplanowane wymagania oraz na przewidywane nieobecności bądź teraz dodatkowe prace, są w stanie stwierdzić czy jest to realny plan, czy też nie.
W szczególności w przypadku kross-funkcjonalnych zespołów i feature teamów gdzie zastępowalność jest dość duża, ciężko jest powiedzieć, że brak jednej z ośmiu osób obniży nasze velocity o jedną ósmą. Także użyteczność miary Capacity wydaje się być dla zespołów mniejsza, niż Velocity. Ta ostatnia jednak ma swoje problemy.
Ryzyka związane z Velocity
Największe ryzyko związane z Velocity, to liczenie go gdy mamy niestabilny zespół i niestabilne wyniki. Jeżeli w jednym Sprincie dowieźliśmy 10 Story pointów, w drugim 50, w trzecim 5, a w czwartym 72 to nasze velocity nie wynosi 34,25. My po prostu nie mamy żadnego Velocity. Podane przeze mnie liczby są zupełnie różne i wydają się być losowe. Jako takie, w żaden sposób nie pomogą przewidzieć nam przyszłości. A przecież do tego używamy Velocity – żeby mieć pojęcie czy nasz plan na kolejny Sprint jest okay, czy nie okay.
Drugie ryzyko jest związane z wystąpieniem sytuacji szczególnych – tych, które próbuje adresować Capacity. Jeżeli mamy świąteczny Sprint albo połowa zespołu poszła na wakacje, albo zdarzyło się coś co spowodowało że zamiast średnich 50 punktów dowieźliśmy 10, to warto się zastanowić czy taki wynik uwzględniać w naszych wyliczeniach. Jednorazowe rzeczy w długim terminie nie mają wpływu na średnią.
Do kategorii „istotnych zmian” należą także wszelkiego rodzaju zmiany w zespołach oraz reorganizacja. Po jakichkolwiek fundamentalnych zmianach w zespole, zwykle zajmuje nam 3-5 iteracji, żeby osiągnąć jakiekolwiek stabilne Velocity. Próby wyliczenia tej wartości wcześniej raczej są wskazane na porażkę.
Przy tej okazji trzeba też podkreślić, że nie ma co porównywać Velocity między zespołami, ponieważ zwykle Story Pointy nie są znormalizowane. A to znaczy że jeden zespół może realizować 50 punktów na Sprint, a drugi 150, pomimo tego że robią dokładnie tą samą robotę. Więcej szczegółów na ten temat znajdziecie w tekście na temat Story Pointów.
Po co nam Capacity i Velocity?
Zarówno Velocity, jak i Capacity mogą być do tego, żeby dobrze się zaplanować. Na Planowaniu Sprintu warto byłoby zobaczyć nasze ostatnie dokonania i zobaczyć czy to, co teraz próbujemy sobie zaplanować jakkolwiek koresponduje z historycznymi wynikami. Wszyscy dobrze wiemy, że w działaniach ciągłych, najlepszym prognostykiem przyszłości jest przeszłość. A jeśli szykują się jakieś nieprzewidziane nieobecności – spróbujmy wyliczyć Capacity.
I tu słowo ostrzeżenia. Nigdy nie powinniśmy planować więcej niż wynosi nasze maksymalne Velocity za kilka ostatnich Sprintów. Gadanie typu „jak się zepniemy, to zrobimy więcej” nie sprawdza się nigdy. Jakkolwiek jestem zwolennikiem tego, żeby próbować pracować lepiej i robić więcej, to jednak musi to mieć sens. Jeśli nasze średnie velocity to 30 punktów, a maksymalne 35 to nie powinniśmy planować więcej niż 30-35. Jeśli chcemy postawić przed sobą wyzwanie, to możemy spróbować zaatakować 37, ale nie próbujmy porywać się na 40, a już na pewno nie na 50.
Z drugiej strony, jeżeli nasze średnie Velocity to rzeczone 30 punktów, to nie ma co planować 20 z nastawieniem, że „jeżeli zostanie nam trochę czasu, to dobierzemy więcej wymagań”. Ani nie zostanie, ani nie dobierzemy, a powodem tego jest dobrze nam znane Prawo Parkinsona.
Drugą rzeczą, do której używamy Velocity i Capacity jest zarządzanie Backlogiem przez Product Ownera. Mając oszacowane Elementy Backlogu Produktu oraz znając średnią prędkość zespołu bądź zespołów, jesteśmy w stanie odłożyć tę prędkość i zobaczyć mniej-więcej w którym Sprincie będą realizowane poszczególne prace. Przykładowo, jeżeli pierwszych 50 elementów to 200 Story Pointów, a nasze zespoły mają średnią prędkość w okolicach 40, to wiemy że te ostatni element pewnie będzie realizowany za około 5 Sprintów, o ile nic się nie zmieni w naszym backlogu. A dobrze wiemy że się zmieni. Dodatkowo, możemy mieć planowane urlopy i np. wdrożenia, co z kolei obniży nasze Capacity.
Pytanie czy te wyliczenia się przydają, jest pytaniem do zespołu i do Product Ownera. Zastanówcie się przede wszystkim, czy Wam się sprawdzają!
