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 w ten sposób 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. Właśnie ta decyzja stanowi planowanie 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 — a „zaangażowanie” po cichu znika już w środę.

Dlaczego, co i jak

W „Przewodniku po Scrumie” planowanie sprintu opiera się na trzech pytaniach, które warto zachować w tej właśnie 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ół. Należy uzgodnić go, zanim zaczną Państwo pracować nad listą zadań. Wyznaczanie celu sprintu to osobna umiejętność.
• Co można zrealizować w tym sprincie? Programiści wybierają zadania z górnej części listy zadań, które służą osiągnięciu celu, aż osiągną granicę swojej pojemnoś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 chodzi o szczegółowe rozpisanie każdej pozycji aż do ostatniego podzadania; wystarczy tyle, by rozpocząć pracę z pewnością siebie.

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

Najpierw określ zakres, potem opracuj plan

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

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 definicji gotowości i wybiera zadania do realizacji, dopóki nie wyczerpie się jego zdolność produkcyjna. Zatrzymajmy się w tym miejscu. Pokusa, by wcisnąć „jeszcze tylko jedną” małą historię, jest właśnie przyczyną nadmiernego obciążania sprintów.

Część druga to planowanie. Teraz zespół szczegółowo analizuje wybrane elementy — dzieli je na zadania, identyfikuje zależności i ustala, kto i od czego zacznie. To właśnie na tym etapie okazuje się, że historia, która wydawała się warta 3 punktów, w rzeczywistości wymaga tygodnia pracy, co kryje się za niejasnym kryterium akceptacji.

Rozdzielenie tych dwóch kwestii pozwala uniknąć sytuacji, w której przy każdym punkcie porządku obrad dyskusja kręci się w kółko między pytaniami „czy powinniśmy to uwzględnić?” a „jak mielibyśmy to zrealizować?”.

Co powinno znaleźć się w pokoju

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 miejscu.

• Udoskonalony, uszeregowany według priorytetów backlog. Najważniejsze pozycje powinny być już dobrze zrozumiałe i z grubsza oszacowane pod względem nakładu pracy. Jeśli podczas planowania zespół po raz pierwszy zapoznaje się z danym zadaniem, oznacza to, że udoskonalanie backlogu odbywa się podczas niewłaściwego spotkania — a spotkanie to będzie się przedłużać. Udoskonalanie służy jako źródło zadań; planowanie jest procesem podejmowania decyzji.
• Rzeczywista wartość zdolności produkcyjnej. Nie chodzi tu 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 omawianie rozwiązań dla 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ą się zrealizować oraz 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 jedynie kolejką zadań.

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 — czyli mniej więcej dwie godziny tygodniowo w trakcie 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ż na etapie planowania. Wystarczy uporządkować dane wejściowe, a spotkanie samo z siebie się skróci. Jeśli potrzebują Państwo szczegółowego harmonogramu z podziałem na minuty, znajdą go Państwo w rozdziale „Porządek 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 zapada żadna decyzja, ponieważ nikt nie podejmuje decyzji — 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 cel ambitny. 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 czas. Należy 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 czas sprintu zaczyna się kurczyć, nie ma żadnych wytycznych co do tego, które z nich należy odrzucić — w rezultacie wszystko się nieco 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 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ć na to około dwóch godzin tygodniowo na sprint — czyli mniej więcej dwie godziny na sprint tygodniowy, cztery na sprint dwutygodniowy, a maksymalnie osiem na miesiąc. Jest to górna granica, a nie cel. Jeśli konsekwentnie potrzebują Państwo całego wyznaczonego czasu, oznacza to zazwyczaj, że lista zadań nie była odpowiednio przygotowana przed rozpoczęciem sprintu.

Jakie są kluczowe etapy planowania sprintu?

Należy potwierdzić rzeczywistą wydajność zespołu na czas sprintu; uzgodnić cel sprintu; wybrać elementy backlogu służące 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łaśnie w tej 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 przedstawia 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 ją zrealizują — to oni sporządzają prognozę, a nie właściciel produktu, który ma za zadanie przydzielać zadania.