Wykorzystaj mój szablon do obliczania capacity dla zespołu scrumowego
Jeżeli pracujesz w SCRUM, a tym bardziej w SAFE jako Scrum Master – to potrzebujesz znać capacity zespołów przed planowaniem sprintu lub Program Increment’u. W tym artykule znajdziesz sposób na obliczenie capacity oraz gotowy do pobrania szablon w formacie xls. Najpierw jednak dowiedz się dlaczego warto zorganizować odpowiednie dane tak a nie inaczej.
Czym jest capacity?
Krótko wyjaśniając jest to pojemność iteracji. Ilość pracy jaką zespół może zaplanować mierzona według przyjętej wcześniej jednostki używanej w poprzednich sprintach.
Pojemność jest to narzędzie służące do znalezienia odpowiedzi na pytanie: ile możecie zrobić w tym sprincie?
Lub: Na kiedy to będzie gotowe?
Albo: czy dowieziecie funkcjonalność do…?
Odpowiedzi na powyższe pytania w formie pojemności iteracji – sprintów, są oczywiście oszacowaniem pracy jaka może zostać wykonana w przyszłości.
Bazuje ona na doświadczeniach zespołu z poprzednich sprintów i charakterystyki planowanych prac.
Dobrze dobrana pojemność wiąże się z umiejętnością trafnego szacowania.
Szacowanie pracy jest nieodzownym elementem planowania a więc jednego z głównych wydarzeń zarówno w SCRUM jak i w SAFE.
Ciekawy artykuł teoretyczny można znaleźć https://bialko.eu/agile/capacity/
Jak zadbać o poprawność oszacowania?
Prawdopodobieństwo poprawnego oszacowania pracy jest wprost proporcjonalna do:
- Zgrania deweloperów w zespole,
- Jednakowe zrozumienie jednostki miary,
- Dokładności przeprowadzonego refinementu
Szacowanie a zgranie deweloperów
Prostym wyjaśnieniem tej zależności jest oczywiście jedna z korzyści płynących z tego że osoby w zespole są ze sobą zgrane – przewidywalność.
Pracując z kimś chcemy być pewni zaangażowania drugiej osoby. Pewni tego że ma ona kompetencje do wykonania planowanych zadań, tego że zapewni wsparcie jeśli będzie ono potrzebne.
Z drugiej strony świadomość tego że osoba z zespołu jest niezaangażowana, że kompetencji nie ma lub je dopiero zdobywa albo że się nie chce dzielić wiedzą też jest formą przewidywalności i sprzyja prawdopodobnemu szacowaniu – mimo że nie jest to koniecznie zespół jaki chcielibyśmy współtworzyć lub budować.
A więc im lepiej się znamy tym lepiej szacujemy.
Stabilność zespołu jest tu kluczowa – ciągłe zaburzenia kadrowe wykluczają prawdopodobne planowanie i capacity zespołu w najlepszym wypadku może być zgadywaniem – przy odpowiednim podejściu wykalkulowanym ale wciąż zgadywaniem.
Dlatego: Biznesie! Inwestuj w zespoły gdyż ich stabilizacja jest kluczem do przewidywalności realizacji twoich planów.
Jednakowe zrozumienie jednostki miary
Tu jako jednostkę miary przyjmę Story Pointy (SP) jako że w pracy z inną się nie spotkałem.
Podkreślam że moja tabela zakłada stosowanie przez zespół empirycznego podejścia do story pointa.
To podejście charakteryzuje się porównywaniem wielkości zadań względem siebie w odniesieniu do wykonanych w przeszłości podobnych elementów backlogu.
Zapomninamy o czasie potrzebnym do ich wykonania.
Mieszanie szacowania empirycznego z tak zwanymi man-day’ami (czyli roboczo dniami przypadającymi na jednego pracownika, w skrócie MD) moim zdaniem zupełnie mija się z celem.
Zespoły które stosują porównanie np. 1SP=0,5MD=4h mogą równie dobrze nie szacować w story pointach tylko przerzucić się na szacowanie w godzinach.
Jednakowość zrozumienia SP jest jak wspólny język którym się posługujemy żeby się skutecznie dogadać.
Dobre szacowanie jest wynikiem pracy zespołu na planowaniu – dyskusji nad sposobem implementacji wymagań biznesowych.
Obrazem tego jest planning poker na którym zespół dyskutuje o złożoności zadań posługując się jedną skalą. Ta dyskusja ma na celu sprowadzenie jednostki miary, tu 1SP do wspólnego mianownika.
Dokładność przeprowadzonego refinementu
Właściciel Produktu podczas dekompozycji elementów backlogu (backlog refinement) tłumaczy wymagania biznesowe. Fantastyczną sytuacją jest refinement poprzedzony pracą Właściciela Produktu z projektantem UX. Daje to deweloperom wizualizację wymagań dzięki czemu są one łatwiejsze do zrozumienia i przekucia na logikę oprogramowania.
Ta zależność jest intuicyjna – im lepiej wiemy co zrobić, tym lepiej wiemy jak.
Pierwsze capacity bywa wzięte z kapelusza
Iteracje które towarzyszą budowaniu zespołu najczęściej są przestrzelone lub niedoszacowane. Wynika to z faktu że któryś z wymienionych wyżej elementów lub kilka na raz kuleje. Te aspekty na pewno są do obserwacji i warto nad nimi pracować.
Uważam że niezbędne są na początku warsztaty które pomogą zespołowi się poznać oraz razem wypracować wspólny system i postrzeganie złożoności pracy z jaką przychodzi im się mierzyć.
Sposób na obliczenie capacity – metoda
Znamy się, mamy wspólną miarę, i dokładnie wiemy co zrobić.
Jak zespół wypowiada powyższe zdanie a ja wieżę że to prawda, to jestem spokojny o planowanie i mogę z pewnością siebie przygotować pojemność. Można stwierdzić że tens sposób na obliczenie capacity jest metodyczny.
Wkładem do metody są (w tabeli na zielono):
- Długość sprintu w dniach
- Ilość deweloperów w zespole
- Nieobecności poszczególnych deweloperów
- Średnia prędkość zespołu z poprzednich sprintów w tym samym składzie
Mając powyższe dane jesteśmy w stanie obliczyć osłabienie procentowe każdego z planowanych sprintów. Oczywiście zakładając że zespół będzie stabilny i jego prędkość będzie podobna do uśrednionej wartości z poprzednich sprintów. W sumie brzmi prosto prawda? Bo jest to faktycznie bardzo proste 🙂
No to teraz trochę matematyki 😛
Na szczęście w arkuszu kalkulacyjnym.
Dane wejściowe
W kolumnach rozpisujemy każdą planowaną iterację dla zespołu Herosi.
Wskazujemy ile trwa iteracja, ile jest członków zespołu, średnią prędkość poszczególnych zespołów i wskazujemy wszystkie nieobecności. Przygotowujemy wszystkie dane wejściowe (w tabeli na zielono). Z iloczynu ilości deweloperów i ilości dni w sprincie wynika całkowita ilość dni roboczych całego zespołu, w poniższym przykładzie 40 – będzie to nasze 100% obecności jakie jest możliwe.
Nieobecności
Pamiętaj że to nie jest planowanie urlopów tylko nieobecności.
Każdy brak rąk do pracy się liczy, niezależnie czy jest to urlop, planowany zabieg medyczny czy święto.
Zaczynasz od wypisywania wszystkich świąt wolnych od pracy które przypadają na każdą iterację.
Jest to element który może mieć wpływ na dodatkowe nieobecności więc warto go pokazać zespołowi na początku.
O ile zasada jest taka że nie pracujemy w święta – każdy deweloper dziedziczy wartość świąteczną:
Następnie zbierasz informacje od deweloperów kiedy planują nieobecności. W indywidualnych już przypadkach są dodawane do nieobecności wynikających ze świąt.
W poniższym przykładzie Marry planuje po 5 dni urlopu w sprintach 35 i 36, Miles 1 dzień urlopu w 37 sprincie a Bill po 5 dni urlopu w sprintach 39 i 40:
Osłabienie prędkości
Iloraz sumy nieobecności wszystkich deweloperów w danym sprincie do sumy wszystkich możliwych dni roboczych jest procentowym osłabieniem danego sprintu (Weekening).
Na przykład w sprincie 35 masz 9/40=0,23
Prędkość po osłabieniu
Średnia prędkość poprzednich sprintów jest zmniejszana o osłabienie prędkości, czyli w 35 sprincie 51,5-(51,5*0,23)=39,9
Bufor bezpieczeństwa
To jest wartość która dodatkowo pomniejsza prędkość aby otrzymać ostateczne capacity.
Bufor bezpieczeństwa (Safety Buffer) jest uznaniowy i zależy od doświadczenia zespołu, planowanych zależności, zastępowalności kompetencji w zespole. W tym przykładzie przyjęte zostało 10%, wartość ta może się różnić między sprintami.
Doświadczonemu w szacowaniu stabilnemu kadrowo zespołowi dałbym mniejszy bufor.
Im więcej zależności tym bufor powinien być większy. Jeśli zespół nie ma wpływu na powstanie niezbędnych elementów np. wytwarzanych przez zespoły systemowe to tym mniej może się zdeklarować na dostarczenie funkcjonalności.
„Ale w tym czasie może być wykonywana inna praca więc na capacity to nie wpływa?” Owszem wpływa chociażby z uwagi na potrzebę przełączania się pomiędzy wątkami.
Jeśli masz brak zastępowalności w zespole to bufor musi być większy. W crossfunkcjonalnym zespole, jeśli deweloper określonej warstwy (np. front end) jest nieobecny to częstokroć zadania nie mogą zostać ukończone.
Jeśli coś jest nie skończone to nie jest skończone.
Pojemność sprintu
Prędkość po osłabieniu dodatkowo pomniejszamy o Safety Buffer i otrzymujemy capacity.
W 35 Sprincie capacity wynosi 39,9-(39,9*10%)=35,9
Wynik ostatecznie zaokrąglamy, w tym przypadku przyjąłbym 36 Story Pointów.
Dopasowanie
„No dobra Michał, fajny sposób na obliczenie capacity ale przecież w dwutygodniowym sprincie na 10 dni roboczych jeden cały dzień odchodzi na ceremonie poza tym mamy refinement i kilka innych spotkań…”
Nie ma problemu, na szczęście mamy arkusz kalkulacyjny z formułami więc zmniejsz odpowiednio ilość dni w sprincie. Uwaga: ilość dni w sprincie dotyczy wszystkich iteracji objętych tą tabelą. W związku z tym zmniejsz odpowiednio biorąc pod uwagę tylko cykliczne spotkania, jak np. refinement, cop lub inne które zdarzają się w każdym sprincie.
Jeżeli pojawiają się długie spotkania które wiadomo że się wydarzą – radzę dostosować Bufor który dotyczy pojedynczego sprintu.
„No dobra Michał, ale powiedz jak to zrobić jeżeli zespół jest wydzielony z większego albo doszła nowa osoba – skład nie jest ten sam co w poprzednich sprintach.”
No tu jest już problem gdyż pojawiają się niewiadome danych wejściowych w postaci średniej prędkości z poprzednich iteracji oraz znajomości członków zespołu.
W takim wypadku, jeżeli np. dochodzi osoba to trzeba polegać na jej szacowaniu przy czym przed planowaniem trzeba znaleźć wspólny mianownik w zrozumieniu Story Pointów. Jeżeli nie ma czasu na warsztaty dotyczące szacowania zadań to można by się oprzeć na wzorcowym, typowym zadaniu, np. na 3 SP.
Nowa osoba widząc złożoność zadania i jego wycenę posłuży się nim by relatywnie szacować większe i mniejsze zadania.
Ważne tu jest przeanalizowanie czy nowa osoba usprawni przepływ pracy czy spowoduje wąskie gardło. W drugim przypadku prędkość może dużo nie wzrosnąć. Dla przykładu dokładamy dewelopera back endu nie dokładając nikogo na front i do testowania. Najprawdopodobniej zespół nie nadąży z budowaniem frontu. Wyjątkiem jest junior danej warstwy który potrzebuje uwagi lub osoba która crossfunkcjonalnie wzbogaci zespół.
Zawsze warto przed dokonaniem zmiany sobie przypomnieć że wszystkie usprawnienia które wykonujemy poza wąskimi gardłami – są iluzoryczne.
Sposób na obliczenie capacity w arkuszu kalkulacyjnym do pobrania
Podsumowując
Zespół oczekuje od Scrum Mastera pomocy w podjęciu właściwej decyzji, a w takich przypadkach jak pojemność i prędkość to aż się prosi żeby podejść do tematu po inżyniersku. Bazowanie na danych które tak pięknie mogą zaserwować nam nasze kochane systemy kontroli zgłoszeń jak JIRA to solidny sposób na obliczenie capacity.
