Jak zaplanować sprint na podstawie prędkości zespołu?

Sprint można zaplanować na dwa różne sposoby. Pierwszy z nich, polega na wykorzystaniu prędkości zespołu (ang. velocity-driven). „Bardzo możliwe, że w tym sprincie zrobimy mniej więcej tyle, co w poprzednim”.

Drugi, ciekawszy, oddaje wszystko w ręce zespołu, który sam decyduje o tym, ile jest w stanie zrobić w sprincie. Jest to planowanie przez zobowiązanie (ang. commitment-driven). Prędkość nie ma tutaj aż tak wielkiego znaczenia.

W trzech kolejnych wpisach, pokażę wam jak planować sprinty za pomocą każdego podejścia, a także powiem, które podejście wybrać.

Zacznijmy od planowania na podstawie prędkości zespołu.

Krok 1. Określ średnią prędkość zespołu z ostatnich kilku sprintów.

Jeżeli macie już kilka sprintów za sobą, sprawa jest prosta. Możemy przyjąć, że mniej więcej tyle samo zrobimy, co ostatnio. To jest trochę tak jak z przewidywaniem pogody na jutro. Dziś mamy jeden z wielu słonecznych dni lata. Jak będzie jutro? Pewnie tak samo. Słońce da nam nieźle popalić.

Technika ta jest jednak bardzo złudna. Jutro może się zmienić front atmosferyczny i będzie na przykład lało. Temperatura spadnie do dwudziestu stopni. Podobnie jest w sprincie. Mamy styczeń. Planujemy sprint. Jaką przyjmujemy prędkość? „Nooo… taką, jak w grudniu, 15 punktów”. No dobra, ale w grudniu były święta, Mieszko był chory, Marcin, przez kilka dni pomagał chłopakom z oddziału w Londynie. Normalnie moglibyśmy spokojnie dużo więcej wyciągnąć.

Dlatego niektóre zespoły przyjmują średnią prędkość z kilku ostatnich sprintów, na przykład trzech. Ja polecam jednak wziąć pod uwagę od 8 do 10 sprintów, jeżeli macie oczywiście taką możliwość. Trzy sprinty, to mimo wszystko wciąż za mało, żeby dać miarodajny wynik.

Co jednak w przypadku, kiedy nigdy wcześniej nie pracowaliście w Scrumie i nie macie zielonego pojęcia, jak szybko „spalacie” pracę? Możecie skorzystać z tych trzech sposobów, które opisałem w oddzielnym wpisie.

Krok 2. Wybierz elementy Backlogu Produktu, które odpowiadają prędkości zespołu.

W następnym kroku, wspólnie z Product Ownerem wybieramy elementy Backlogu Produktu, nad którymi będziemy pracować w sprincie. Tutaj kluczowe znaczenie ma prędkość zespołu, którą wcześniej oszacowaliśmy, no i priorytety. Na tej podstawie możemy zdecydować jak poukładać naszą pracę w najbliższych kilku tygodniach.

Załóżmy, że przewidywana prędkość zespołu to 15 punktów. Mając tę informację wiemy, że łączna wielkość planowanych historyjek użytkownika (popularny format elementów Backlogu) nie może przekroczyć tej magicznej liczby. Okazuje się, że według priorytetów, które ustaliliśmy wspólnie z Product Ownerem, możemy dobrać tylko cztery historyjki − łącznie 13 punktów. Gdybyśmy dołożyli kolejną, która ma 5 punktów, moglibyśmy już przeholować. Wówczas, dałoby to nam łącznie 18 punktów, czyli o 3 więcej niż pozwala nam na to oszacowana prędkość. I, w zasadzie, na tym etapie planowanie sprintu na podstawie prędkości zespołu się kończy. Jednak większość zespołów idzie krok dalej i dekomponuje historyjki użytkownika na odpowiadające im zadania, a następnie je szacuje. W tym podejściu jednak to nie jest konieczne.

Gdybyście jednak chcieli spróbować, zamieszczam dwa kolejne kroki.

Krok 3. Podziel wybrane elementy Backlogu Produktu na odpowiadające im zadania (OPCJONALNIE)

Spróbujcie pomyśleć o każdej, nawet najmniejszej aktywności, którą musicie wykonać, żeby dostarczyć coś, co działa i cieszy oczy Product Ownera na koniec sprintu.

Dzielenie na zadania, to wspólna praca całego zespołu. Siadamy w sali konferencyjnej, najlepiej z dużą tablicą, przynosimy stos żółtych karteczek, coś do pisania i możemy zaczynać.

Czytamy pierwszą historyjkę. Zaczyna się dyskusja. Prawdopodobnie nie unikniecie rozmów o szczegółach technicznych, możliwych rozwiązaniach. To zupełnie normalne. Ale nie brnijcie za daleko. Szczegóły dopracujecie, jak tylko ruszycie z robotą w sprincie.

Gdyby się okazało, że o czymś zapomnieliście lub zadania zostały źle zdefiniowane i trzeba coś poprawić, dodać – spokojnie możecie to zrobić później, w trakcie trwania sprintu.

Scrum jest bardzo elastyczny pod tym względem. W tradycyjnych projektach, jak trzeba było coś zmienić, zawsze było wielkie halo. Tutaj nie ma tego problemu.

Dowiedziałeś się czegoś nowego i potrzebujesz dostawić nowe zadanie – zrób to. Jakieś zadanie przestało być potrzebne – usuń je. Musisz coś doprecyzować – śmiało.

I znowu, niektóre zespoły na tym etapie kończą. Nie szacują zdekomponowanych zadań. Ale oczywiście możecie to zrobić. To wy jesteście panami swojego losu. To wy sami zarządzacie swoją pracą w sprincie.

A więc kolejny krok… 😉

4. Oszacuj zadania (OPCJONALNIE)

Zadania szacujemy w idealnych godzinach. Jeżeli uważacie, że coś zajmie wam 4 godziny, wpiszcie 4 godziny.

Są zespoły, które najpierw, na małych karteczkach, wypisują wszystkie zadania i potem je szacują. Inni szacują po każdym zadaniu. Zdecydujcie sami.

W kolejnym wpisie opiszę wam, jak planować sprint na podstawie zobowiązania zespołu. A na razie zostawiam was z tym materiałem. Do następnego poczytania za tydzień! 😉