Prędkość a pojemność zespołu. Czym się różnią?

Cykl: Zwinna Firma
4 stycznia 2018

4

Czym różni się prędkość od pojemności zespołu w Scrumie. Dzisiaj odpowiadam na jedno z pytań, które otrzymałem:

„Czy nie jest trochę tak, że prędkość zespołu odnosi się do elementów, które stanowią tylko wartość dodaną w produkcie? Biorąc wszystko pod uwagę, historyjki, błędy, spike – mówimy o całościowej pracy wykonanej czyli pojemności, a nie prędkości”.

(Damian R.)

Moja odpowiedź:

W jednym i drugim przypadku mówimy o prędkości zespołu (ang. velocity). Są dwie definicje prędkości, które najczęściej się stosuje:

  1. Prędkość, to liczba funkcjonalności, które zespół dostarczył w sprincie.
  2. Prędkość, to wysiłek zespołu potrzebny do „przekucia” pomysłów na nowe funkcjonalności w sprincie.

Która definicja jest poprawna?

Obie definicje są poprawne. Różnice polegają głównie na sposobie zliczania prędkości w poszczególnych sprintach.

Żeby to lepiej zrozumieć, posłużę się prostym przykładem.

Załóżmy, że mamy dwa zespoły. Pierwszy z nich, zrealizował w sprincie 3 historyjki użytkownika: A, B i C. Żeby było prościej – przyjmijmy, że pracochłonność każdej z nich wynosi dokładnie 3 punkty.

Backlog Sprintu Zespołu 1:

  • Historyjka A: 3 pkt
  • Historyjka B: 3 pkt
  • Historyjka C: 3 pkt

Drugi zespół, zrealizował w sprincie tylko 2 historyjki użytkownika: D, E (też za 3 punkty każda). I jeden błąd, który powstał przy implementacji historyjki E. Zespół oszacował, że jego naprawa zajmie również 3 punkty.

Backlog Sprintu Zespołu 2:

  • Historyjka D: 3 pkt
  • Historyjka E: 3 pkt
  • Naprawa błędu (E1): 3 pkt

Jeden i drugi zespół zrealizował wszystkie historyjki w sprincie. W przypadku pierwszego zespołu, sprawa jest prosta. Prędkość tego zespołu równa się 9 punktów. Co jednak z zespołem nr 2? Czy jego prędkość to 6, czy może 9 punktów? No właśnie.

Wszystko zależy od tego, którą definicję prędkości zastosujemy. Jeżeli pierwszą, to 6. Jeżeli drugą, czyli uwzględniając naprawę błędu (E1), to 9.

Jak widzicie, w tym wszystkim bardzo ważne jest, żeby cały Wasz zespół, PO i SM mieli takie samo rozumienie „prędkości”. W przeciwnym wypadku, może dojść do niepotrzebnych zgrzytów.

Software jak silnik lotniczy

Ja jestem zdecydowanym fanem definicji nr 2. Wyobraźcie sobie, że software, który dostarczacie jest silnikiem lotniczym o dużej mocy. Takie silniki cechuje duża niezawodność i pewność pracy. Wszystko fajnie, ale co by było, gdyby linie lotnicze nie robiły żadnych przeglądów technicznych swoich maszyn? Co by było, gdyby od czasu do czasu nie wymieniały zużytych elementów w swoich silnikach?

W dyskusjach, o silniku lotniczym, słyszę czasem argumenty, że przecież przeglądy techniczne, naprawy usterek nie mają wpływu na realną wartość samolotu. Jeżeli Boeing 737 kosztuje, dajmy na to 100 mln USD, to zrobienie przeglądu nie zwiększy jego ceny.

To prawda. Tylko, czy takie rozumienie wartości ma zastosowanie w przypadku produktów wytwarzanych w Scrumie? Nie. Bezpieczeństwo pasażerów, zmniejszenie ryzyka katastrofy, są dla mnie jako pasażera cholernie ważne i nie chcę wsiadać do maszyny, która nie ma regularnych przeglądów silnika. To jest dla mnie wartość i mam nadzieję, że dla linii lotniczych również 🙂

„Czysta” wartość biznesowa

Zauważcie, że my bardzo podobnie zachowujemy się w naszych projektach. Chcemy dostarczać tylko wartość biznesową w najczystszej możliwej postaci. Bo to jest coś, co cieszy oko Product Ownera, prawda? 🙂

W ogóle nie bierzemy pod uwagę: zadań technicznych, błędów, refaktoringu kodu, automatyzacji testów, usprawnień związanych z procesem integracji i budowania. Bo to nie ma przecież żadnej wartości dla PO.

I, jak obserwuję, w firmach toczą się małe wojenki o to, kto się tym powinien zająć. IT dogaduje się Biznesem – ile procent czasu w sprintach powinniśmy poświęcać na rzeczy „niewartościowe” 🙂 Albo nawet sam zespół przekonuje Product Ownera do tego, że chomikowanie długu technicznego to kiepski pomysł.

Jeżeli używacie definicji prędkości nr 2, jest trochę łatwiej się dogadać i znaleźć wspólną płaszczyznę porozumienia w tym temacie.

Prędkość vs. pojemność

Na koniec chciałem się jeszcze odnieść do „pojemności zespołu” (ang. team capacity), która pojawiła się w pytaniu.

Pojemność zespołu (ang. team capacity) jest najczęściej wykorzystywana przy planowaniu sprintów na podstawie zobowiązania zespołu. Na jej podstawie, zespół decyduje o tym, ile elementów backlogu jest w stanie wziąć do sprintu.

Jeżeli zespół ma dużo zajęć „pozalekcyjnych” (dostępność niska), to weźmie mniej. Jeżeli jego dostępność wynosi 100%, to podejmie się realizacji większej liczby historyjek w sprincie.

Na oszacowanie dostępności zespołu wpływa szereg różnych czynników: rozmiar zespołu, urlopy, aktywności organizacyjne (np. spotkania firmowe, szkolenia organizacyjne, zaangażowanie w inne projekty typu wsparcie procesu rekrutacji itp.). Dlatego dostępność zespołu różni się między zespołami (podobnie zresztą jak prędkość).

Prędkość z kolei, może być wykorzystywana przy planowaniu sprintu, ale jest również bardzo fajnym miernikiem, który może Wam pomóc przy planowaniu długofalowym w Scrumie (np. trzy miesiące do przodu, planowanie wydań itp.). Ja głównie wykorzystuję prędkość, w tym drugim przypadku, bo tutaj świetnie się sprawdza. A do planowania sprintów używam z zespołami najczęściej pojemności.