Jak zaplanować sprint na podstawie zobowiązania zespołu?

W poprzednim odcinku naszego cyklu, krok po kroku, opisałem wam jak można zaplanować sprint na podstawie prędkości zespołu.

Dzisiaj pokażę wam drugi sposób planowania, w którym prędkość zespołu nie ma już tak wielkiego znaczenia.

No, to zaczynamy! 😉

W tym podejściu, zanim zabierzecie się za planowanie sprintu, Product Owner musi dobrze przemyśleć listę najważniejszych elementów Backlog Produktu, przed samym spotkaniem.

Najlepiej jest wykorzystać do tego jedną z sesji pielęgnacyjnych, w których uczestniczyliście w poprzednim sprincie.

Krok 1. Omów najważniejsze elementy Backlogu Produktu

Product Owner, krok po kroku wymienia i krótko omawia najważniejsze historyjki, które chciałby zrealizować w nadchodzącym sprincie.

Krok 2. Określ dostępność zespołu.

Ustalamy jaka jest dostępność zespołu w sprincie. Tutaj, możecie na sztywno założyć, że każdy z was poświęca od 4 do 6 godzin na realizację sprintowych zadań. Albo, określić swoją dostępność indywidualnie. Ja osobiście wolę ten drugi sposób, bo jest dokładniejszy.

Pamiętajcie, że mówimy o czasie idealnym, a więc czasie, który tylko i wyłącznie poświęcacie na wykonywanie zadań w sprincie.

Ja, żeby było łatwiej, zwykle używam rozróżnienia na „czas brutto” i „czas netto”.

Czas brutto, to łączny czas, który każdego dnia spędzacie w firmie, czyli 8 godzin. Ten czas może zawierać różne aktywności – na przykład czytanie i odpisywanie na maile, udział w szkoleniach organizacyjnych (np. szkolenie BHP), pomoc w realizacji innych projektów, przerwy – ale także zadania wykonywane w sprintach.

Czas netto natomiast, to czas, który w całości poświęcacie na prace sprintowe. Nie wliczamy do niego żadnych dodatkowych zadań, które macie do zrobienia w firmie.

Załóżmy, że wasz zespół składa się z 4 osób, a sprint trwa 10 dni. Wasza szacunkowa dostępność może w tym wypadku wyglądać tak:

Krok 2. Wybierz najważniejszą historyjkę z listy

Kiedy wiemy już, jaką mamy dostępność w sprincie, sięgamy do Backlogu Produktu i wybieramy najważniejszą historyjkę z listy.

Krok 3. Podziel historyjkę na zadania i oszacuj je w godzinach

W kolejnym kroku, dekomponujemy historyjkę na zadania i szacujemy je w idealnych godzinach. I tutaj są dwa podejścia. Możecie dzielić historyjkę na zadania i od razu je szacować. Albo zrobić to na końcu. To zależy od was. Ja zwykle robię to drugie.

Pamiętajcie też, że nie musicie tracić czasu na definiowanie wszystkich możliwych zadań w sprincie. Po pierwsze, jest to niemożliwe. Po drugie, nie ma takiej potrzeby.

W trakcie sprintu, i tak dojdą wam zadania, o których wcześniej nigdy byście nie pomyśleli.

Krok 4. Czy damy radę?

Kiedy podzielicie topową historyjkę z Backlogu na zadania i oszacujecie je w godzinach, zastanówcie się, czy faktycznie dacie radę ją zrobić.

Na początku, przez pierwszych kilka sprintów, zwykle Scrum Master zadaje zespołowi to pytanie – „Czy dacie radę?”

Ale idea jest taka, żeby to ludzie w zespole, sami przed sobą deklarowali, że są w stanie coś zrobić, albo i nie. Taka deklaracja jest trwalsza i dużo bardziej autentyczna niż pojedyncze obietnice składane na przykład swojemu szefowi.

Dlatego Scrum Master, już od pierwszych sprintów powinien wspierać samoorganizację zespołu. Tak bardzo jak tylko jest to możliwe.

Krok 5. Dobieramy kolejne historyjki

W kolejnym kroku de facto powtarzamy to, co robiliśmy w trzech poprzednich.

Na podstawie priorytetów w Backlogu, dobieramy kolejne historyjki, dekomponujemy je na zadania, które później szacujemy w idealnych godzinach.

I, uwaga! Musicie dobrać tyle historyjek, żeby nie przekroczyć 230 godzin. Bo tyle wynosi szacowana dostępność zespołu w sprincie.

Dlatego też, za każdym razem, kiedy rozbijecie daną historyjkę na zadania i oszacujecie je – musicie sprawdzić, ile idealnych godzin zostało wam jeszcze do końca.

Jeżeli zespół uzna, że dobieranie kolejnej historyjki nie ma już sensu – przerywacie. W naszym wypadku może się okazać, że już przy 150 godzinie nie damy rady zrobić reszty 🙂

Jak nam poszło?

Jak się już pewnie zdążyliście zorientować, przy planowaniu przez zobowiązanie, to czy szacujemy historyjki w punktach, czy dniach idealnych nie ma wielkiego znaczenia, jak w poprzednim podejściu.

Mimo to, zachęcam was do tego, żeby całkowicie nie rezygnować z wyceny historyjek. Punkty, czy dni idealne mogą wam się przydać, żeby na przykład ocenić, czy to, co zaplanowaliście znacząco odbiega od tego, co było w poprzednim sprincie. A jeżeli tak, to dlaczego tak się dzieje?

Żeby to zrobić, wystarczy zsumować wyceny wszystkich elementów Backlogu Produktu, które wybraliście do sprintu. W ten sposób zobaczycie, jaka jest wasza szacowana prędkość w sprincie.

Teraz, będziecie mogli ją porównać z ostatnią lub średnią z kilku ostatnich prędkości w sprintach i ocenić, jak bardzo wasz plan różni się od poprzedniego? Czy zaplanowaliście więcej? A może mniej?

Załóżmy, że średnia prędkości z kilku ostatnich sprintów wynosi 25 punktów. Jeżeli okaże się, że do sprintu wybraliście historyjki za łączną sumę 24 punktów – zaplanowaliście mniej więcej tyle samo pracy, co w poprzednim sprincie.

Z kolei, jeżeli zaplanowaliście tylko 15 punktów, możecie się zastanawiać dlaczego udało wam się zaplanować 15 punktów, podczas gdy wcześniej planowaliście 25.

W takich sytuacjach bardzo często jest tak, że w trakcie planowania zespół definiuje zadania, o których wcześniej, w trakcie szacowania, w ogóle nie wiedział. Albo zakładał, że są one częścią innej historyjki.

Podobna sytuacja może wystąpić też w drugą stronę. Może się na przykład okazać, że do sprintu wybraliście historyjki, za łącznie 37 punktów.

I znowu. Pojawia się pytanie, skąd taka duża liczba? Dlaczego w trakcie szacowania te same historyjki były mniej pracochłonne, a teraz już nie są? Może o czymś zapomnieliśmy?

Jak widzicie, wiedza na temat historycznej prędkości zespołu może wam się bardzo przydać. Mimo, że punkty, czy dniówki idealne nie mają w tym podejściu do planowania aż wielkiego znaczenia.

W następnym, ostatnim już, odcinku naszego cyklu, podpowiem wam którą metodę planowania wybrać. Stay tuned! 😉