Spotkanie dotyczące planowania sprintu – krok po kroku

Planowanie sprintu to spotkanie, które rozpoczyna sprint. Podczas tego spotkania zespół uzgadnia cel sprintu i ustala, jaką część zaległości może realistycznie zrealizować, przekształcając listę priorytetów w plan, w który zespół rzeczywiście wierzy. Zaległości pozostają listą życzeń, dopóki ktoś nie zdecyduje, co zostanie zrealizowane w następnej kolejności. Decyzja ta zapada właśnie podczas planowania sprintu.

Jeśli wszystko przebiegnie prawidłowo, zajmuje to godzinę lub dwie, a zespół wychodzi ze spotkania, wiedząc, co ma robić i dlaczego. Jeśli jednak przebiegnie to nieprawidłowo, zamienia się to w sesję przeglądania listy zadań, podczas której właściciel produktu przydziela zgłoszenia, a wszyscy tylko kiwają głowami, po czym „zaangażowanie” po cichu zanika już w środę.

Dlaczego, co i jak

W „Przewodniku po Scrumie” planowanie sprintu opiera się na trzech pytaniach, które warto zachować w tej kolejności:

• Dlaczego ten sprint jest wartościowy? Odpowiedź tkwi w celu sprintu: jednym zdaniem, za którym może się zjednoczyć cały zespół. Proszę uzgodnić go, zanim zaczną Państwo pracować nad zaległościami. Wyznaczenie celu sprintu to osobna umiejętność.
• Co można zrealizować w tym sprincie? Programiści wybierają z listy zadań do realizacji pozycje znajdujące się na początku listy, które służą osiągnięciu celu, aż do wyczerpania swoich możliwości. Jest to prognoza, a nie obietnica złożona pod przysięgą.
• W jaki sposób zostanie zrealizowane wybrane zadanie? Zespół dzieli najważniejsze pozycje na elementy w stopniu wystarczającym do rozpoczęcia prac: zadania, sposób postępowania oraz oczywiste ryzyka. Nie rozbija się każdej pozycji aż do ostatniego podzadania; wystarczy tyle, by rozpocząć pracę z pewnością siebie.

Wynikiem tego procesu jest lista zadań sprintu: cel, wybrane zadania oraz plan ich realizacji.

Najpierw określ zakres, a potem opracuj plan

Najbardziej przydatnym nawykiem organizacyjnym jest przeprowadzanie planowania w dwóch odrębnych etapach, a nie w jednym nieprecyzyjnym.

Część pierwsza dotyczy zakresu. Właściciel produktu przedstawia cel oraz potencjalne zadania w kolejności według priorytetów. Zespół zadaje pytania wyjaśniające, sprawdza każde zadanie pod kątem zgodności z definicją gotowości i wybiera zadania do realizacji, dopóki nie wyczerpie się jego zdolność produkcyjna. Na tym należy się zatrzymać. Pokusa, by „jeszcze tylko jedno” dodać małe zadanie, jest właśnie przyczyną nadmiernego obciążania sprintów.

Część druga to planowanie. Teraz zespół dogłębnie analizuje wybrane elementy, dzieląc je na zadania, identyfikując zależności oraz uzgadniając, kto i od czego rozpocznie pracę. To właśnie na tym etapie odkrywa się, że zadanie, które wydawało się mieć priorytet 3, w rzeczywistości wymaga tygodnia pracy, co kryje się za niejasnym kryterium akceptacji.

Rozdzielenie tych dwóch kwestii pozwala uniknąć sytuacji, w której podczas każdego posiedzenia dyskusja kręci się w kółko między pytaniami „czy powinniśmy to przyjąć?” a „jak mielibyśmy to zrealizować?”.

Co należy zapewnić w pomieszczeniu

Planowanie sprintu przebiega skutecznie tylko wtedy, gdy dane wejściowe są już gotowe. Spotkanie służy przekształceniu tych danych w plan; nie tworzy się ich na bieżąco.

• Udoskonalona lista zadań z ustalonymi priorytetami. Najważniejsze pozycje powinny być już dobrze zrozumiałe i z grubsza oszacowane pod względem nakładu pracy. Jeśli zespół po raz pierwszy zapoznaje się z danym zadaniem właśnie podczas planowania, oznacza to, że udoskonalanie listy zadań odbywa się podczas niewłaściwego spotkania, a samo spotkanie będzie się przedłużać. Udoskonalanie służy jako podstawa; planowanie jest etapem podejmowania decyzji.
• Rzeczywista wartość zdolności produkcyjnej. Nie chodzi o „dwa tygodnie pomnożone przez liczbę członków zespołu”, lecz o godziny faktycznie dostępne po odliczeniu urlopów, spotkań, dyżurów wsparcia oraz czasu poświęconego na przerwy w pracy. Zobacz: planowanie prędkości i zdolności produkcyjnej.
• Cały zespół. To programiści sporządzają prognozę, więc to oni muszą w tym uczestniczyć. Planowanie za pośrednictwem innych osób prowadzi do podjęcia zobowiązań, za które nikt nie bierze odpowiedzialności.

Kto tym kieruje

Scrum Master pełni rolę moderatora: dba o przestrzeganie ram czasowych, zapewnia rozdzielenie obu etapów oraz zapobiega przekształceniu się spotkania w szczegółowe omawianie każdego skrajnego przypadku. Właściciel produktu przedstawia cel oraz uporządkowany backlog, a także na bieżąco odpowiada na pytania „dlaczego” i „co”. Programiści decydują, jaką część zadania podejmą i w jaki sposób ją zrealizują.

Ta ostatnia kwestia ma znaczenie: prognoza należy do osób wykonujących tę pracę. Plan narzucony z góry i przyjęty w milczeniu nie stanowi zobowiązania. Jest to jedynie kolejka.

Ile to powinno zająć

W Przewodniku po Scrumie przewidziano na planowanie maksymalnie osiem godzin w przypadku sprintu trwającego jeden miesiąc oraz proporcjonalnie mniej w przypadku sprintów krótszych, co daje w przybliżeniu dwie godziny tygodniowo w ramach sprintu. W przypadku sprintu trwającego dwa tygodnie czas ten powinien wynosić około czterech godzin, a często nawet mniej, gdy zespół osiągnie stałe tempo pracy.

Proszę traktować to jako górną granicę, a nie cel. Zespoły, które nieodmiennie potrzebują całego wyznaczonego czasu, niemal zawsze dopracowują szczegóły już podczas planowania. Proszę zadbać o odpowiednie dane wejściowe, a spotkanie samo z siebie się skróci. Jeśli potrzebują Państwo szczegółowego podziału na minuty, znajdą go Państwo w rozdziale poświęconym porządkowi obrad planowania sprintu.

Gdzie pojawiają się problemy

Większość nieudanych spotkań dotyczących planowania wynika z trzech rodzajów błędów.

Sesja przeglądu. Właściciel produktu omawia zgłoszenia, a zespół słucha. Nie podejmuje się żadnych decyzji, ponieważ nikt nie decyduje; członkowie zespołu są jedynie informowani. Planowanie powinno sprawiać wrażenie, że to zespół dokonuje wyboru, a nie że zadania są mu przydzielane.

Nadmierne zobowiązanie. Zdolność produkcyjna traktowana jest jako ambitny cel. Zespół przyjmuje swoją najwyższą dotychczasową wydajność jako minimum i dodaje do tego nieco ambicji. Wystarczy jednak awaria systemu wsparcia, dzień zwolnienia lekarskiego i jedna niedoceniona zadanie, by sprint zamienił się w gorączkową walkę o termin. Proszę planować w oparciu o skromne założenia, a nie heroiczne.

Planowanie bez celu. Zespół wybiera zbiór niepowiązanych ze sobą zgłoszeń, a gdy termin sprintu się zbliża, brakuje jasnych zasad dotyczących tego, które z nich należy odrzucić, w związku z czym wszystko nieco się opóźnia i żadne rozwiązanie nie zostaje dostarczone w idealnym stanie. To właśnie cel wskazuje, które zgłoszenia należy odrzucić w sytuacji presji.

Przygotuj dane wejściowe, oddziel zakres od planu i pozwól zespołowi przejąć odpowiedzialność za prognozę. W dalszej części niniejszego przewodnika szczegółowo omówiono każdy z tych elementów. Zacznij od ustalenia porządku obrad lub skorzystaj z szablonu planowania sprintu.

Najczęściej zadawane pytania

Czym jest planowanie sprintu?

Planowanie sprintu to wydarzenie w ramach metodyki Scrum, które rozpoczyna sprint. Zespół uzgadnia cel sprintu, wybiera elementy backlogu, które według prognoz uda się zrealizować, oraz nakreśla sposób wykonania pracy. Odpowiada na trzy pytania: dlaczego sprint ma wartość, co zostanie zrealizowane oraz w jaki sposób.

Jak długo powinno trwać planowanie sprintu?

Proszę zaplanować czas na około dwie godziny tygodniowo na sprint, czyli mniej więcej dwie godziny na sprint tygodniowy, cztery na sprint dwutygodniowy i maksymalnie osiem na miesiąc. Jest to górna granica, a nie cel. Jeśli konsekwentnie potrzebują Państwo całego wyznaczonego czasu, zazwyczaj oznacza to, że lista zadań nie była odpowiednio przygotowana przed rozpoczęciem sprintu.

Jakie są kluczowe etapy planowania sprintu?

Proszę potwierdzić rzeczywistą wydajność zespołu na dany sprint; uzgodnić cel sprintu; wybrać elementy z listy zadań, które służą realizacji tego celu, aż do osiągnięcia pełnej wydajności; podzielić najważniejsze elementy na wykonalny plan; oraz upewnić się, że zespół uznaje tę prognozę za wiarygodną. Najpierw należy określić zakres, a dopiero potem opracować plan – w tej właśnie kolejności.

Kto prowadzi spotkanie dotyczące planowania sprintu?

Scrum Master pełni rolę moderatora i dba o przestrzeganie wyznaczonych ram czasowych. Właściciel produktu dostarcza uszeregowany pod względem priorytetów i dopracowany backlog oraz wyjaśnia uzasadnienie poszczególnych zadań. Programiści decydują, ile pracy są w stanie podjąć i w jaki sposób zrealizują zadania: to oni sporządzają prognozę, a nie właściciel produktu, który ma im przydzielać zadania.