Szablon agendy planowania sprintu dla zespołów inżynierskich

Dlaczego sprinty się przeciążają

Planowanie sprintu ma jedną strukturalną porażkę, której szablony nie zapobiegają: zespoły wybierają backlog sprintu, zanim ktokolwiek sprawdzi dostępność. Efektem jest sprint, który wyglądał na wykonalny na tablicy, a rozpada się do środy, gdy dwóch inżynierów jest nieobecnych przez pół tygodnia, jeden ticket potraja swój zakres, a trzy elementy miały niewypowiedziane zależności od usługi, którą zespół platformowy właśnie przepisuje.

Rozwiązanie jest proste i niemal nigdy niestosowane: zobowiąż się do dostępności przed zobowiązaniem się do pracy. Poniższy szablon otwiera się przeglądem dostępności dokładnie z tego powodu.

Agenda (do skopiowania)

Czas trwania: 2 godziny dla sprintu dwutygodniowego; 1 godzina dla sprintu tygodniowego
Format: prowadzony, z backlogiem widocznym dla całego zespołu

Sekcja 1 — Cel sprintu (10 min)

Jedno zdanie: jak wygląda udany sprint z zewnątrz?
Cel powinien być na tyle konkretny, by dowolny członek zespołu mógł na koniec sprintu ocenić, czy go osiągnęliście
Odrzucaj cele, które są tylko listą ticketów („dokończyć refaktor auth i stronę rozliczeń") — to backlog, a nie cel

Sekcja 2 — Przegląd dostępności (15 min)

Wymień każdego członka zespołu z imienia
Dla każdego: zaplanowany urlop, rotacja dyżurów, cykliczne spotkania, znane zobowiązania zewnętrzne
Wyraź dostępność jako dostępne story pointy lub dni — nie jako liczbę osób
Ta liczba to sufit; nie wybieraj więcej pracy, niż on udźwignie

Sekcja 3 — Wybór z backlogu (45 min)

Przejdź przez elementy o najwyższym priorytecie z dopracowanego backlogu
Dla każdego kandydata: czy zespół ma dość, żeby zacząć, czy są otwarte pytania wymagające odpowiedzi przed startem sprintu? Otwarte pytania należą do kolejki dopracowania, a nie do sprintu
Przestań wybierać, gdy dobijesz do 80% dostępności; pozostałe 20% wchłania przelewki i pracę nieplanowaną

Sekcja 4 — Kryteria akceptacji (20 min)

Dla każdego wybranego elementu: podaj kryterium, które czyni go ukończonym
Jeśli zespół nie potrafi podać kryterium w 60 sekund, ticket nie jest dostatecznie dopracowany — przenieś go z powrotem do backlogu
Zapisz je w tickecie teraz, na sali; nie polegaj na „dodamy później"

Sekcja 5 — Ryzyka i zależności (15 min)

Co mogłoby zablokować dostarczenie celu sprintu, a jest poza kontrolą zespołu?
Nazwij właściciela zależności; wydobądź ją teraz, póki jest czas, by ją rozwiązać przed połową sprintu
Nierozwiązane zależności dostają nazwanego właściciela z zespołu, który będzie je śledził

Zamknięcie (15 min)

Potwierdź, że cel sprintu wciąż jest ważny w świetle wybranej pracy
Wyznacz protokolanta podsumowania sprintu albo potwierdź konfigurację automatycznego raportu
Potwierdź datę kolejnego planowania

Czego brakuje większości szablonów planowania sprintu

Najpopularniejsze szablony planowania sprintu skupiają się na porządkowaniu backlogu i definicji ukończenia. Oba są ważne. Żaden nie adresuje błędu planistycznego, który wytwarza najwięcej porażek sprintów: wyboru pracy bez sprawdzenia dyspozycyjności.

Zespół pięciu inżynierów przy pełnej dostępności ma z grubsza 200 story pointów na dwutygodniowy sprint. Zespół pięciu z dwoma inżynierami na urlopie, jednym na rotacji dyżurów i jednym na trzydniowym wyjeździe integracyjnym ma może 110. Jeśli w tym drugim sprincie wybierzesz 180 pointów, już poniosłeś porażkę. Krok wyboru to moment, w którym dochodzi do przezobowiązania, a dostępność musi go poprzedzać.

Druga luka to kryteria akceptacji. Zespoły przelatują przez planowanie i zamierzają napisać kryteria później. Później nie dzieje się na tym samym poziomie precyzji. Osoba, która na sali napisałaby dokładne kryterium, następnego dnia pisze z pamięci coś mętniejszego albo nie pisze wcale. Spory w środku sprintu o to, co znaczy „ukończone", niemal zawsze da się prześledzić do pominiętych kryteriów akceptacji w planowaniu.

Kumulujący się koszt tych luk — przeciążone sprinty, odkrycia w środku sprintu, na nowo roztrząsane definicje — widać jasno, gdy się to zsumuje: Podatek od spotkań.

Dlaczego notatki z planowania sprintu są trudniejsze, niż się wydaje

Planowanie sprintu generuje więcej informacji niż niemal każde inne cykliczne spotkanie: cel sprintu, liczby dostępności, uzasadnienie wyboru element po elemencie, kryteria akceptacji dla każdego ticketu, właściciele zależności, elementy ryzyka. Napisanie użytecznego podsumowania wymaga uchwycenia tego wszystkiego w formie użytecznej trzy dni później, gdy ktoś zapyta „dlaczego wycięliśmy tamten element?".

Pavleur generuje raport z planowania sprintu automatycznie na koniec rozmowy. Ujmuje cel sprintu, wybrany backlog wraz z uzasadnieniem, kryteria akceptacji w brzmieniu, jakie padło na spotkaniu, i właścicieli zależności tak, jak zostali nazwani. Jeśli ktoś udostępnił na ekranie backlog albo arkusz dostępności, ten materiał wizualny jest włączony do raportu obok dyskusji — kontekst, który narzędzia oparte tylko na dźwięku, takie jak Otter czy Fireflies, całkowicie by zgubiły. Każdy, kto dołączył późno lub potrzebuje sprawdzić decyzję w środku sprintu, ma pełny zapis. Porównanie, jak różni się to od narzędzi opartych tylko na dźwięku: Pavleur na tle alternatyw.

Obsługa zmiany planu w środku sprintu

Plan sprintu to zobowiązanie, a nie kontrakt. Gdy coś w środku sprintu naprawdę unieważnia plan — incydent produkcyjny, krytyczna zależność blokująca trzy tickety, zmiana priorytetów od kierownictwa — właściwą reakcją jest szybka rozmowa o przeplanowaniu, a nie ciche porzucenie zakresu. Rozmowa o przeplanowaniu trwa 20 minut i wytwarza zaktualizowany cel sprintu odzwierciedlający rzeczywistość. Alternatywą jest sprint, który na papierze zawodzi, a nieformalnie zostaje dostosowany w sposób, którego nikt nie zapisał, przez co retrospektywa staje się trudniejsza, a liczby velocity bez znaczenia.

Wyrób nawyk jawnego przeplanowania. Użyj tej samej struktury: zaktualizowana dostępność, poprawiony wybór, ponownie sformułowany cel. Zajmuje to dużo mniej czasu niż zamęt, któremu zapobiega.