Capacity planning, czyli kilka słów o pojemności w Scrum

Capacity planning, czyli planowanie pojemności, to jeden z istotnych elementów zarządzania pracą zespołu w Scrumie. Dzięki odpowiedniemu oszacowaniu pojemności zespołu możliwe jest bardziej precyzyjne planowanie Sprintu oraz minimalizacja ryzyka przeciążenia członków zespołu. W niniejszym artykule wyjaśniamy, czym jest capacity, jak je obliczać, jakie czynniki na nie wpływają oraz jak radzić sobie z dynamicznymi zmianami w trakcie Sprintu.

Co to jest capacity w Scrum?

W Scrum pojemność zespołu odnosi się do ilości pracy, jaką zespół może zrealizować w trakcie Sprintu, biorąc pod uwagę dostępność członków zespołu oraz ich produktywność. Capacity obok Velocity stanowi kluczowy parametr podczas planowania Sprintu, który mówi o nadchodzącym Sprincie. Dzięki uwzględnieniu pojemności zespół może realistycznie zaplanować swoje działania, unikając przeciążenia oraz utraty jakości dostarczonego przyrostu produktu. Planowanie pojemności jest integralną częścią Sprint Planning i opiera się na empirycznych danych historycznych oraz na bieżącej ocenie dostępności członków zespołu.

W odróżnieniu od past performance, które najczęściej jest określane jako Velocity i wyrażone w jednostce abstrakcyjnej, capacity wyrażana jest najczęściej w jednostkach czasu, takich jak godziny czy dni robocze. Pojemność zespołu może być także wyrażana procentowo w porównaniu do idealnego Sprintu.

Ciągłe planowanie Sprintów, które kończą się tym, że elementy nie są ukończone, tylko część elementów udaje się zamknąć w ramach Sprintu i ciągle są spady do kolejnych Sprintów, spowoduje dużą demotywację Developerów i poczucie bezsensu planowania w Scrumie. Po co planować, jeśli nigdy nam nie wychodzi? Interesariusze też zaczną coraz głośniej wyrażać niezadowolenie i wątpić w Scruma, jeżeli nie można przewidzieć, co dostarczy Zespół Scrum. Korzystanie z capacity planning może pomóc Zespołowi Scrum skuteczniej planować Sprinty i lepiej zdać sobie sprawę z realnych ograniczeń. 

“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.”
Scrum Guide 2020

W przypadku wąskiej specjalizacji Developera w Zespole Scrum sprawdzenie indywidualnego capacity pomaga w optymalnym wykorzystaniu wąskiego gardła w procesie.

Jak liczyć capacity?

Obliczanie capacity wymaga kilku kroków: określenia dostępności członków zespołu, uwzględnienia nieobecności i innych zadań poza Sprintem, oraz finalnie podsumowania czasu, który zespół może poświęcić na pracę w danym Sprincie. Należy także wziąć pod uwagę czas potrzebny na spotkania zespołowe oraz margines bezpieczeństwa (bufor), który pozwoli na elastyczne reagowanie na zmiany. Zespół Scrum pracuje nad złożonymi problemami, więc planowanie zadań w Sprincie do 100% dostępnego capacity często powoduje problemy. Najważniejszym elementem obliczeń jest realne podejście do dostępności zespołu, które eliminuje ryzyko błędnych założeń i przeciążenia developerów.

Żeby policzyć capacity, powinniśmy z czasu trwania Sprintu odjąć wydarzenia Scrumowe, dni wolne od pracy, zaplanowaną nieobecność (urlopy, szkolenia itp.) dla każdego członka zespołu. Pozostałą ilość dni można pomnożyć przez ilość godzin dostępnych dla wykonania pracy z uwzględnieniem bufora.

Na przykład dla dwutygodniowego Sprintu możemy policzyć 10 dni roboczych. Od tego powinniśmy odjąć Planowanie Sprintu, Sprint Review, Sprint Retrospective, czyli 4h + 2h + 1,5h. W zaokrągleniu odejmijmy jeden dzień. Daily Scrum i Product Backlog Refinement też zabierają czas, więc przyjmijmy jeden dzień na te spotkania. Zostało nam 8 dni. Biorąc pod uwagę przerywniki i niespodziewane zdarzenia, przyjmijmy 6h pracy Developera dziennie. To daje nam 48h na jednego developera. Jeśli mam 6 developerów, to suma zadań w Sprincie powinna być w okolicach 288h. Jeżeli ktoś nie jest przypisany do zespołu na 100%, wypada nam święto itp., to ilość godzin powinna odpowiednio spaść. Możemy też spojrzeć, jaka była suma godzin na zadaniach w poprzednim Sprincie.

Oczywiście Scrum Guide nie wymaga szacowania zadań w godzinach, bo wspomina jedynie o rozbijaniu elementów Backlogu Produktu na elementy wielkości jednego dnia lub mniej. Jeżeli Zespół Scrum uważa, że rozbijanie wszystkich elementów na zadania i dodatkowe szacowanie zadań w godzinach nie jest przydatną praktyką, może policzyć, ile procent capacity ma dostępne w porównaniu do idealnego Sprintu. Jeżeli nie mamy jednej osoby z 6 developerów, to nasze capacity wynosi 83%. Jeżeli przy capacity 100% zrobiliśmy 25 Story Pointów, to w tym Sprincie rozsądne będzie wziąć maksymalnie 21.

Aby lepiej zrozumieć proces obliczania capacity, przydatne mogą okazać się szkolenia Scrum Master, które oferują zaawansowaną wiedzę na temat zarządzania pracą w Scrum.

Jakie czynniki wpływają na capacity w Scrum?

Capacity zespołu Scrum jest dynamiczne i zależy od wielu czynników, takich jak dostępność członków zespołu (urlopy, choroby), używane narzędzia oraz efektywność środowiska pracy. Istotną rolę odgrywają także doświadczenie zespołu oraz jakość komunikacji, które mogą znacząco wpłynąć na wydajność pracy. Jeżeli nie będziemy sprawnie usuwać przeszkód na drodze zespołu w bieżącym Sprincie, to pojemność nie będzie optymalnie wykorzystana, bo pojawią się zbyt duże przestoje albo Developerzy zaczną pracować nad czymś, co nie było zaplanowane. Rozpoznanie tych czynników i zarządzanie nimi pozwala zespołowi na lepsze wykorzystanie dostępnych zasobów oraz na bardziej efektywne realizowanie celów Sprintu. 

W zespołach, gdzie Developerzy mają specjalistyczne umiejętności, proste policzenie capacity całego zespołu się nie sprawdzi. Trzeba sprawdzić obłożenie specjalistyczną pracą danej osoby i odpowiednio zdecydować o priorytetach. Jeżeli mam w zespole tylko jedną osobę, która zna moduł decyzyjny do obsługi zamówień, to nie możemy wziąć zbyt dużo elementów wymagających zmian w tym module. Product Owner musi zdecydować, jakie inne elementy bez tej pracy możemy wykonać w Sprincie.

Scrum zakłada małe, stabilne zespoły. Jednak jeżeli w rzeczywistości skład zespołu zmienia się ze Sprintu na Sprint, planowanie na podstawie capacity będzie działało lepiej niż korzystanie ze średniej Velocity.

Do analizy i optymalizacji pracy zespołu warto wykorzystać narzędzia takie jak tablica Scrum i wykres spalania (burndown chart), które pomagają w wizualizacji przepływu pracy i identyfikacji blokad. Warto też monitorować Sprinty uwzględniając dostępne capacity i Velocity. Dobrym rozwiązaniem jest stworzenie dodatkowego arkusza lub strony Wiki, jeśli narzędzia do wizualizacji pracy w Sprincie jasno nie pokazują takich danych.

Jak dostosować capacity w dynamicznych warunkach?

Dynamiczne warunki pracy, takie jak zmiany priorytetów czy pojawienie się nieoczekiwanych przeszkód, wymagają elastycznego podejścia do planowania capacity. Codzienne inspekcje podczas Daily Scrum umożliwiają zespołowi bieżące dostosowywanie planów i reagowanie na zmiany. Kluczowe jest także pozostawienie rezerwy czasowej, która pozwala na elastyczność w realizacji zadań. Dobrą praktyką jest zaplanowanie zadań do 80% capacity Zespołu. Jeżeli ciągle mamy dodatkową nieplanowaną pracę, która odciąga Developerów lub powoduje znaczące zmiany w zadaniach, warto obniżyć poziom capacity, do którego planujemy. Może dodatkowe 20% buforu na pojemności Zespołu Scrum pomoże lepiej zaplanować Sprint.

Dostosowywanie capacity w dynamicznych warunkach wymaga od zespołu zarówno transparentnej komunikacji, jak i umiejętności szybkiego podejmowania decyzji na podstawie aktualnych danych. 

W przypadku chęci rozwijania umiejętności radzenia sobie z takimi wyzwaniami przydatne mogą być szkolenia Professional Scrum Master, które uczą zaawansowanego zarządzania zespołem i jego pojemnością.

Czy capacity planning to mikromanagement?

Każda praktyka może zostać wypaczona i użyta ze złą intencją, jednak capacity planning jest na to bardzo podatne. Ta praktyka ma pomóc Zespołowi Scrum, a dokładniej Developerom lepiej zaplanować kolejny Sprint. Można ją stosować w postaci dokładnych wyliczeń albo jako przybliżenie. Z czasem niektóre zespoły rezygnują z szacowania zadań i obliczania capacity, bo na przykład korzystanie z Velocity jest wystarczające.
Capacity planning często kojarzy się niestety z capacity utilization, czyli podejścia do zarządzania, gdzie ludzi traktuje się jak zasoby i trzeba się upewnić, że zasób jest w pełni obciążony. Jeżeli planowanie z pomocą liczenia pojemności skupia się na każdym indywidualnym Developerze i zadania w Sprincie są od razu przypisywane do poszczególnych osób tak, żeby każdy był zajęty na 100%, to mamy zwykły mikromanagement. Pytanie, komu i do czego to jest potrzebne? Jeśli jakiemuś managerowi, to na pewno nie możemy mówić o samozarządzającym się Zespole Scrum. Można do tego skonfigurować tablicę Scrum tak, żeby swimlane był per Developer zamiast per PBI i statusować codziennie zalogowanie 8h na taskach. Co to ma wspólnego ze Scrumem? Tylko nazwę.

Podsumowanie

Capacity planning w Scrum to narzędzie, które pomaga zespołowi lepiej zarządzać swoją pracą i osiągać cele Sprintu. Precyzyjne określenie pojemności zespołu, regularna inspekcja oraz elastyczne reagowanie na zmiany to fundamenty skutecznego planowania Sprintu. Dzięki odpowiedniemu podejściu Zespół Scrum może nie tylko efektywnie wykorzystać dostępne zasoby, ale także zbudować bardziej przewidywalny i wydajny proces pracy. Dodatkowo skuteczne zarządzanie capacity pozwala na minimalizację ryzyka przeciążenia członków zespołu oraz lepsze dostosowanie planów do rzeczywistej dostępności Developerów. W dłuższej perspektywie umożliwia to zespołowi nie tylko osiąganie lepszych wyników, ale również budowanie atmosfery zaufania i współpracy, co przekłada się na wyższą satysfakcję zarówno członków zespołu, jak i interesariuszy.