
Czym jest Capacity zespołu? Czy jest tym samym co Team Velocity?
Otóż nie, choć są to koncepty dość blisko powiązane ze sobą. O Velocity więcej będzie w oddzielnym wpisie. Tu skupię się na kilku przemyśleniach odnośnie Team Capacity.
Team Capacity
Kiedy szacujemy wykonanie jakiegoś zadania wysoko poziomowo, jak np. dostarczenie nowej funkcjonalności, opieramy się na tzw. estymatach, czyli oszacowaniu pracy w godzinach.

Załóżmy, że taka wstępna wycena to będzie 600 h. No dobra, teraz zastanówmy się, co to oznacza dla zespołu w kontekście potencjalnych terminów dostarczenia.

Czy młody kapitan znajdzie odpowiedź na krańcu wszechświata?
A no nie wiele, póki nie będziemy wiedzieć, jaką wielkość ma zespół. Znając wielkość zespołu, będziemy wstępnie mogli ustalić, ile godzin pracy zespół jest w stanie zapewnić podczas Sprintu. Tak, wstępnie.
Kalkulacja taka jest oczywiście dość prosta. Sprint to 2 tygodnie. Zespół to 5 osób. Każdy pracownik w ciągu tygodnia pracuje 40 h, czyli w ciągu iteracji będzie to 80 h. Teraz mnożymy te 80 h przez ilość osób w zespole, powiedzmy 5 i daje nam to 400 h.
Formuły
Capacity
Capacity (na Sprint)= Ilość osób w zespole x 80 h |
Capacity = 5 x 80 |
Capacity = 400 h |
Dalej, dzieląc wycenioną na 600 h parce przez Capacity, otrzymamy ilość potrzebnych Sprintów do wykonania zadania. Co nam daje 1.5 Sprintu.
Ilość Sprintów do realizacji
Estymata / Capacity = Ilość potrzebnych Sprintów |
600 h / 400 h = 1.5 Sprint |
Można na tym polegać
No dobra, ale czy rzeczywiście możemy na takich danych polegać? Oczywiście – to zależy. Jeśli wystarczą nam bardzo ogólne wstępne liczby, to pewnie tak. Jeśli jednak ktoś ma nas potem rozliczać na takiej podstawie, to trzeba się zastanowić. (więcj o planowaniu Sprintu).
Większa precyzja
No właśnie, nie ma tu jeszcze precyzji. Przecież nie uwzględniamy tu czasu, który zespół spędza na spotkaniach. Trochę tego jest, chociażby podstawowe ceremonie scrumowe, urlopy, święta, chorobowe. Zebrane doświadczenie oraz świadomość jak nasz zespół działa, podpowiedzą nam jak rzeczywiście kształtuje się realna Capacity.
Scrum Team Velocity Planner
Jeśli nie masz takiego doświadczenia warto posiłkować się doświadczeniem innych. W arkuszu Scrum Team Velocity Planner przedstawiam takie rozwiązania.
Czy to wystarczy
Tu warto się upewnić, czy oszacowana praca to samo kodowanie, czy też całość pracy związaniem z dostarczeniem funkcjonalności. Czy testowanie było częścią tej wyceny? Czy wycena zawiera przygotowanie środowisk i potrzebnej infrastruktury – jeśli takowe były potrzebne? Warto takie rzeczy sprawdzić przed „skomitowaniem” się do realizacji i dokonać korekty, jeśli taka jest potrzebna.

Teraz horror dostępny w promocyjnej cenie.
Zobacz również:
Czym jest Capacity – podsumowanie
W zależności jak daleko jesteśmy jeszcze od rozpoczęcia pracy, potrzeba w określeniu precyzja zarówno estymaty, jak i capacity zmienia się.
Jeśli potrzebna jest capacity zespołu „na szybko” bo trzeba wstępnie przedstawić ile Sprintów nam to zajmie bez wiążących deklaracji, to ok. Jeśli zaś stoimy przed wejściem w zobowiązanie, trzeba to zrobić precyzyjnie i brać pod uwagę tyle aspektów, ile jesteśmy w stanie zidentyfikować.
W narzędziu Scrum Team Velocity Planner zrobisz to precyzyjnie, obliczając zarówno Velocity, jak i Capacity zespołu.

Chcesz wejść do IT? Szukasz branży z pracą zdalną w pełnym wymiarze?
Jeśli jesteś zainteresowany pracą w IT, zachęcam do eksplorowania bloga. Dużo bardziej szczegółowo omawiam software development w książce Almanach Informatyczny – Lite.
Jej założeniem jest wprowadzenie każdego do świata IT w 100 słowach i turbo kompaktowych definicjach. Wszystko, czego potrzebujesz, żeby świadomie wybrać rolę dla siebie i czuć się komfortowo, kiedy już zaczniesz.
Powiązane wpisy:
- Estymowanie w Scrumie
- Czym zajmuje się Scrum Master
- Czym zajmuje się Product Owner
- Co to jest Scrum w IT?
- Co to jest Agile w IT?
- Co to jest Product Backlog w IT?
- Jak pisać User Story
- Czym zajmuje się Scrum Master?
- Praca w IT bez doświadczenia
- Praca w IT bez programowania
- Czy angielski jest konieczny w IT
- Humanista w informatyce
- Rekrutacja w IT
- (Nie)techniczna skala wejścia do IT
- Jak się pracuje w IT – czy to wszystko mit?
Zobacz także:
- Jak dostać awans
- Jak znaleźć pracę w korporacji
- Cechy dobrego Product Ownera
- 8 cech dobrego Scrum Mastera
- Co to jest API
- Co to jest REST API
- Co to jest CRUD
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle?
- Czy to wszystko mit? – czyli jak na prawdę pracuje się w IT?
- Humanista pośród informatyków
- Informatyk w informatyce.
- Umysł ścisły w informatyce
- Geograficzna eksploracja IT
- Zastosowanie sztucznej inteligencji
- Zmysły sztucznej inteligencji.
- AI w IT. Koniec dominacji ludzkiego intelektu?
Dodaj komentarz