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ół faktycznie 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 sprawnie, zajmuje to godzinę lub dwie, a zespół wychodzi ze spotkania, wiedząc, co ma robić i dlaczego. Jeśli natomiast przebiegnie to nieudolnie, 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 właśnie kolejności:

• Dlaczego ten sprint ma wartość? Odpowiedź tkwi w celu sprintu: jednym zdaniem, za którym może stanąć cały zespół. Proszę 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ń do wykonania, 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 trzeba szczegółowo rozbijać każdej pozycji aż do ostatniego podzadania; wystarczy tyle, by rozpocząć prace z pewnością siebie.

Wynikiem 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 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ół dogłębnie analizuje wybrane elementy, dzieląc je na zadania, identyfikując zależności i uzgadniając, kto i od czego zacznie. To właśnie na tym etapie okazuje się, że zadanie, które wydawało się warte 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 podczas omawiania każdego pojedynczego punktu dyskusja kręci się w kółko między pytaniami „czy powinniśmy to uwzględnić?” 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 miejscu.

• Udoskonalony, uszeregowany według priorytetów backlog. Najważniejsze pozycje powinny być już dobrze zrozumiane i z grubsza oszacowane pod względem nakładu pracy. Jeśli zespół po raz pierwszy zapoznaje się z daną historią podczas planowania, 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 informacji; planowanie jest procesem decyzyjnym.
• Rzeczywista wartość wydajności. Nie „dwa tygodnie pomnożone przez liczbę członków zespołu”, lecz liczba godzin faktycznie dostępnych po odliczeniu urlopów, spotkań, dyżurów wsparcia oraz czasu poświęconego na przerwy w pracy. Zobacz planowanie prędkości i wydajności.
• Cały zespół. To programiści sporządzają prognozę, więc to właśnie oni muszą w tym uczestniczyć. Planowanie z udziałem osób trzecich prowadzi do podjęcia zobowiązań, za które nikt nie ponosi odpowiedzialności.

Kto tym kieruje?

Scrum Master pełni rolę moderatora: czuwa nad przestrzeganiem ram czasowych, dba o 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 przyjmą 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 to jedynie kolejka.

Ile czasu 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 do osiągnięcia. 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 się skróci. Jeśli potrzebują Państwo szczegółowego harmonogramu z podziałem na minuty, znajdą go Państwo w rozdziale „Program planowania sprintu”.

Gdzie pojawiają się problemy

Za większość nieudanych spotkań dotyczących planowania odpowiadają trzy rodzaje błędów.

Sesja zapoznania się z materiałami. Właściciel produktu omawia zgłoszenia, a zespół słucha. Nie podejmuje się żadnych decyzji, ponieważ nikt nie decyduje; zespół jest jedynie informowany. Planowanie powinno sprawiać wrażenie, że to zespół dokonuje wyboru, a nie że zadania są mu przydzielane.

Nadmierne zobowiązanie. Pojemność traktuje się jako cel ambitny. Zespół przyjmuje swoją najwyższą dotychczasową wydajność jako minimum i dodaje do tego nieco ambicji. Wystarczy jednak awaria systemu wsparcia, dzień chorobowy 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 przypadkowych, niepowiązanych ze sobą zgłoszeń, a gdy czas sprintu zaczyna się kurczyć, brakuje jasnych zasad dotyczących tego, które z nich należy odrzucić, w wyniku czego wszystko nieco się opóźnia i żadna z funkcji nie zostaje wdrożona w sposób dopracowany. To właśnie cel wskazuje, które zgłoszenia należy odrzucić w sytuacji presji.

Przygotujcie dane wejściowe, oddzielcie zakres od planu i pozwólcie zespołowi przejąć odpowiedzialność za prognozę. W dalszej części niniejszego przewodnika szczegółowo omówiono każdy z tych elementów. Zacznijcie od porządku obrad lub skorzystajcie 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 i maksymalnie osiem na miesiąc. Jest to górna granica, a nie docelowa wartość. 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 w ramach 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ół wierzy w tę prognozę. 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 czuwa nad przestrzeganiem wyznaczonych ram czasowych. Właściciel produktu dostarcza uszeregowany pod względem priorytetów i dopracowany backlog oraz wyjaśnia uzasadnienie. 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 im przydzielać zadania.