7

Prędkość zespołu (ang. velocity) wyraża liczbę punktów albo dni idealnych (osobodni), które zespół jest w stanie dostarczyć w danym sprincie.

Obliczamy ją w bardzo prosty sposób. Sumujemy wszystkie punkty (lub idealne dni) przypisane do historyjek, które zostały zaakceptowane przez Product Ownera na koniec sprintu.

Zobaczcie na rysunek poniżej poniżej. Jak łatwo zauważyć, historyjka D nie została zakończona, dlatego prędkość zespołu wynosi 10, a nie 12 punktów.

Główny problem z szacowaniem prędkości zespołu pojawia się na początku, kiedy nie wystartowaliśmy jeszcze z żadnym sprintem i nie mamy żadnego doświadczenia w pracy ze Scrumem, żadnych mierników, których moglibyśmy użyć.

Można sobie z tym poradzić na 3 możliwe sposoby:

1. Wykorzystaj dane historyczne

Prawie wszystkie standardy zarządzania projektami trąbią o potrzebie gromadzenia danych historycznych. I bardzo dobrze. Mieć takie mierniki to prawdziwy skarb. Ale często, nawet będąc w ich posiadaniu, możemy się nieźle „przejechać”.

Bo dane historyczne faktycznie mogą się przydać, gdy projekt, którego wielkość mamy oszacować niewiele rożni się od „starego”, realizowanego w przeszłości.

Wystarczy na przykład niewielka zmiana w składzie zespołu projektowego, czy w stosowanej technologii, i psu na budę nasze pomiary.

Dlatego zanim zdecydujecie się na wykorzystanie danych historycznych do szacowania prędkości zespołu, spróbujcie sobie wcześniej odpowiedzieć na kilka pytań:

• Czy używacie tej samej technologii?
• Czy nie zmieniła się domena?
• Czy nie zmienił się skład zespołu?
• Czy nie zmienił się Właściciel Produktu?
• Czy używaliście tych samych narzędzi?
• Czy nie uległo zmianie środowisko pracy?
• Czy parametry projektu szacowały te same osoby?

Jeżeli przynajmniej na jedno z tych pytań, odpowiedź brzmi „nie”, dwa razy się zastanówcie, zanim zaczniecie korzystać z danych historycznych.

Jeżeli jednak, mimo wszystko, zdecydujecie się na wykorzystanie danych historycznych do oszacowania prędkości zespołu, spróbujcie uwzględnić czynnik niepewności z tym związany.

Załóżmy, że w poprzednim projekcie, na którym chcemy się wzorować zrobiliście 10 sprintów. W tym czasie, zespół spalił łącznie 170 punktów. Możemy, więc powiedzieć, że jego średnia prędkość to 17 punktów.

Teraz spróbujemy uwzględnić czynnik niepewności, związany z waszymi szacunkami.

Ja, zawsze używam do tego „lejka niepewności”. Pierwsze widełki są największe i zakładają bardzo duży czynnik niepewności projektu (60% i 160%). Przy pierwszych sprintach proponuję właśnie ten wskaźnik zastosować.

Mnożymy więc 17 punktów odpowiednio przez 0,6 i 1,60. W ten sposób, otrzymamy dwie przewidywane wartości prędkości zespołu: 10 punktów (pesymistyczna) i 27 punktów (optymistyczna).

Zdaję sobie sprawę, że widełki, które otrzymaliśmy są bardzo duże. Ale, uwierzcie mi, w takiej sytuacji nie ma lepszego, bezpieczniejszego rozwiązania.

2. Poobserwuj 2-3 sprinty

To jest mój ulubiony sposób. Jeżeli tylko macie ten komfort, żeby uruchomić taki poligon doświadczalny, to bardzo was zachęcam.

Pilotaż 2-3 sprintów, to jeden z lepszych sposobów na oszacowanie prędkości zespołu w momencie startu. Kiedyś wdrażałem Scruma w organizacji, w której upłynęło trochę czasu, zanim zarząd podjął strategiczną decyzję, żeby wszystkie projekty stosowały tę metodę w swojej codziennej pracy.

W tym czasie, zespoły nie próżnowały. Sprint po sprincie zbierały dane na temat prędkości, którą uzyskiwali. Później, przy planowaniu mieliśmy „z górki”.

Dane, które uzyskacie w wyniku takich pomiarów, podobnie jak w poprzednim przypadku, trzeba odpowiednio przetworzyć i uwzględnić czynnik niepewności.

Załóżmy, że uruchomiliśmy 3 pilotażowe sprinty. W każdym z nich, kolejno, poruszaliśmy się z następującą prędkością: 10, 14 i 15 punktów. Żeby obliczyć widełki, wystarczy zagarnąć wartości skrajne: 10 (prędkość pesymistyczna) i 15 (prędkość optymistyczna).

Możecie też do tego użyć „lejka niepewności”.

Zasady są bardzo podobne do tych, które opisałem w przypadku danych historycznych. Obliczamy średnią prędkość zespołu, a potem stosujemy odpowiedni mnożnik, dzięki czemu będziemy mogli wyrazić ją za pomocą skali.

Im więcej obserwowanych sprintów, tym bardziej przesuwamy się na „lejku” w prawo. Czynnik niepewności będzie malał. Poniżej mała ściąga, która ułatwi nam dalsze szacowanie.

Weźmy dane z poprzedniego przykładu: 10, 14 i 15. Średnia prędkość w tym przypadku to 13 punktów. Ponieważ przyglądaliśmy się tylko 3 sprintom, zastosujemy mnożnik 0.85 i 1.15. W ten sposób, otrzymamy widełki w postaci 11. i 15. punktów.

3. Spróbuj przewidzieć

Załóżmy, że nie możecie wykorzystać danych historycznych i nie macie czasu na zabawę w „podglądacza”. Co wtedy?

Są takie projekty, które ruszą dopiero za sześć lub więcej miesięcy. Albo data rozpoczęcia projektu zależy od podpisania kontraktu przez klienta. W pierwszym przypadku nie chcemy ponosić dodatkowych kosztów. Bo i po co. Może nic z tego nie wyjdzie. Poza tym sporo rzeczy może się jeszcze zmienić. Nasze estymaty siłą rzeczy będą obarczone dużym poziomem niepewności i ryzyka.

A czekający klient? Nie mamy danych historycznych, które moglibyśmy naprędce użyć. Nie ma też czasu na eksperymenty. Potrzebujemy szybkiego rozwiązania – zupy „instant”.

Poniżej krótka instrukcja, jak można do tego podejść.

Krok 1. Oszacuj dostępność zespołu w sprincie w idealnych godzinach.

Pamiętajcie o tym, że nigdy nie jest tak, że sto procent swojego czasu poświęcacie na zadania w projekcie. Zawsze wpada nam coś ekstra – rekrutacja nowych pracowników, telefony, spotkania organizacyjne, wsparcie innych zespołów, szacowanie nowych projektów, inspekcje kodu etc.

Czy my mamy w ogóle czas na pracę? Zazwyczaj przyjmuje się, że pracownik średnio poświęca od czterech do sześciu godzin dziennie na działania w projekcie.

Załóżmy, że mamy oszacować projekt, w którym będzie pracowało 6 osób: architekt, dwóch programistów, dwóch testerów i jeden bazodanowiec.

Zakładamy bardzo optymistycznie, że każda osoba, każdego dnia będzie mogła poświęcić 6 godzin na pracę w sprincie. Wiedząc, że długość sprintu wynosi 10 dni roboczych, razem mamy 250 idealnych godzin do rozdysponowania na cały sprint. Co dalej?

Krok 2. Losowo wybierz kilka elementów backlogu i oszacuj ich wielkość.

Teraz potrzebujemy w jakiś sposób zasymulować robotę. W tym celu, wybieramy, na chybił trafił, kilka reprezentatywnych elementów backlogu. Mogą to być funkcjonalności, które już wcześniej implementowaliście lub rzeczy całkiem nowe, wymyślone na potrzebę chwili.

Ważne jest, żeby wszyscy je rozumieli i wiedzieli, co się za nimi kryje. I, szacujemy. Określamy, jaki jest punktowy rozmiar każdej historyjki.

Krok 3. Podziel historyjki na zadania i oszacuj je w idealnych godzinach.

Zastanawiamy się, na jakie zadania możemy podzielić historyjki. Co jest faktycznie do zrobienia? Analiza, przygotowanie projektu technicznego, spotkania, kodowanie, testy… Kawałek po kawałku, rozbieramy wybrane historyjki na małe części. Następnie, szacujemy zadania w idealnych godzinach.

Krok 4. Dobieraj historyjki do momentu, aż nie przekroczysz dostępności zespołu w sprincie.

Proces ten przypomina trochę posługiwanie się tradycyjną wagą. Na jednej szalce mamy dostępność zespołu, a na drugiej elementy Backlogu, niczym odważniki. Dokładamy pojedyncze historyjki do momentu, gdy uzyskamy równowagę. W praktyce, może to wyglądać na przykład tak:

Pamiętajcie, że nie zawsze będziecie w stanie dobrać historyjki w ten sposób, żeby idealnie odpowiadały godzinom, które zadeklarował zespół.

W naszym przypadku, zabrakło nam 9 godzin do 250. Gdybyśmy jednak dobrali kolejną historyjkę, to mogłoby się okazać, że przekroczyliśmy założony limit.

Krok 5. Oszacuj prędkość zespołu (w punktach).

Teraz mamy już z górki. Wystarczy zsumować wszystkie, dobrane w poprzednim kroku, historyjki, dodać punkty, dodać godziny i już. Mamy prędkość. W naszym przypadku, to 26 punktów.

Krok 6. Oszacuj optymistyczną i pesymistyczną prędkość zespołu (w punktach).

Wykorzystujemy „lejek”. Ponieważ bazowaliśmy tylko na jednym sprincie, stosujemy mnożnik 60% i 160%. W ten sposób uzyskujemy następujący zakres prędkości: 16 i 30 punktów.

***

Te trzy podejścia pozwolą Wam oszacować prędkość zespołu, zanim wystartujecie ze swoim pierwszym sprintem.

Jeżeli znacie jeszcze inny sposób, o którym tu nie wspomniałem, koniecznie dajcie znać w komentarzach.