Jak poprowadzić Scrumowe spotkanie Sprint Planning

Przed spotkaniem: checklista przygotowania

• Doprecyzuj górę backlogu — elementy o najwyższym priorytecie powinny być jasne, oszacowane i na tyle małe, by zmieścić się w sprincie.
• Potwierdź pojemność — zanotuj planowane urlopy, święta i rotacje supportowe. Wyrażaj pojemność jako dostępne developer-days lub story pointy.
• Przejrzyj poprzedni sprint — wykorzystaj wnioski z retrospektywy i review, aby określić, co jest realistyczne w tym sprincie.
• Przygotuj szkic Celu Sprintu — Product Owner zwykle przychodzi z propozycją; zespół dopracowuje ją wspólnie.

Przewodnik facylitacji krok po kroku

1. Zacznij od Celu Sprintu (5–10 min)
   Product Owner przedstawia cel. Zespół dyskutuje, czy jest osiągalny, jasny i wartościowy. Dopracujcie wording wspólnie, aż wszyscy będą aligned.
2. Przejrzyj pojemność (5 min)
   Podsumuj dostępne dni robocze na każdego developera. Porównaj z historyczną velocity zespołu w story pointach, aby ustalić realistyczną górną granicę dla sprintu.
3. Wybierz elementy backlogu (15–30 min)
   Weź elementy z góry dopracowanego backlogu, które wspierają Cel Sprintu i mieszczą się w pojemności. Użyj story pointów jako lekkiego sprawdzenia rozmiaru. Szybko oszacuj ponownie każdy element, który istotnie zmienił się od czasu refinementu.
4. Użyj planning pokera dla niejasnych estymat (10–20 min)
   Jeśli zespół musi ponownie oszacować lub zwymiarować nowe elementy, użyj planning pokera. Otwórz darmową sesję online, dodaj historie, głosujcie jednocześnie, omówcie różnice i zbieżcie się — zwykle w 2–3 rundach na historię.
5. Rozbij historie na zadania (15–20 min)
   Developers identyfikują pracę potrzebną do spełnienia Definition of Done. Uchwycenie zadań wcześnie ujawnia ukrytą złożoność i zależności.
6. Zidentyfikuj ryzyka i zależności (5 min)
   Wskaż wszystko, co może zablokować dostarczenie: brakujące projekty, API stron trzecich, zewnętrzne akceptacje. Dodaj jawne zadania lub spike’i dla każdego ryzyka.
7. Commit i zamknięcie (5 min)
   Zespół potwierdza Sprint Backlog i Cel Sprintu. Scrum Master aktualizuje sprint w narzędziu do zarządzania projektem i zamyka spotkanie.

Wskazówki facylitacyjne

• Chroń timebox — jeśli dyskusja odpływa, zaparkuj temat i idź dalej. Rozwiąż go w follow-upie lub podczas sprintu.
• Trzymaj Cel Sprintu na pierwszym planie — każdy wybrany element powinien mu służyć.
• Nie commituj 100% pojemności — zostaw 10–20% na nieoczekiwaną pracę, bugi i support.
• <strong>Używaj narzędzi przyjaznych pracy zdalnej</strong> — jeśli zespół jest rozproszony, udostępniaj ekrany, korzystaj z wirtualnej tablicy i uruchamiaj online planning pokera, aby głosować jednocześnie.
• Zapisuj kluczowe decyzje — zanotuj Cel Sprintu, pojemność i wszystkie odroczone elementy w narzędziu backlogowym, zanim wszyscy wyjdą.

Typowe antywzorce, których warto unikać

• Rozpoczynanie z niedopracowanym backlogiem — prowadzi do długich dyskusji, brakującego kontekstu i słabych estymat.
• Pomijanie Celu Sprintu — zostawia zespół bez kompasu, gdy priorytety zmieniają się w połowie sprintu.
• Nadmierny commitment — optymistyczne planowanie ignorujące pojemność prowadzi do nieudanych sprintów i niskiego morale.
• Królicze nory estymacyjne — timeboxowanie każdej estymaty historii do 5–10 minut utrzymuje sesję w ruchu.
• Product Owner decydujący, co zespół może zrobić — Developers są właścicielami planu; Product Owner jest właścicielem celu.

Rola Scrum Mastera w Sprint Planningu

Scrum Master nie prowadzi Sprint Planningu w tradycyjnym sensie moderatora spotkania.

Praktycznie Scrum Master przygotowuje się potwierdzając, że elementy backlogu są zrefinowane i gotowe.

• Przed planowaniem: potwierdź z Product Ownerem, że główne elementy backlogu są gotowe.
• Podczas planowania: ogranicz czasowo każdą dyskusję, zarządzaj rundami Planning Pokera.
• Po planowaniu: zarejestruj Sprint Goal w narzędziu śledzenia.

Rola Product Ownera w Sprint Planningu

Product Owner jest głosem wartości biznesowej w Sprint Planningu.

Najskuteczniejsi Product Ownerzy przychodzą na Sprint Planning po przygotowawczej rozmowie ze Scrum Masterem.

• Zaproponuj Sprint Goal: sformułuj go jako wynik biznesowy, nie listę funkcji.
• Wyjaśnij zakres, nie implementację: wyjaśnij, jak wygląda sukces dla każdej historii.
• Bądź dostępny przez całą sesję: Product Ownerzy, którzy wychodzą po przedstawieniu celu, zostawiają zespół niezdolny do odpowiadania na pytania.

Efektywne prowadzenie Sprint Planningu dla zdalnych zespołów

Zdalny Sprint Planning wprowadza wyzwania, z którymi planowanie osobiste radzi sobie organicznie.

Utrzymanie zaangażowania zdalnych uczestników

• Kamery włączone podczas głosowania: jakość dyskusji Planning Pokera poprawia się, gdy uczestnicy widzą się nawzajem.
• Wkłady round-robin przy dekompozycji zadań: poproś każdego uczestnika o nazwanie jednego zadania.
• Używaj parking lota widocznie: utrzymuj udostępnioną i widoczną listę tematów poza zakresem.

Narzędzia wspierające zdalny Sprint Planning

• Narzędzie Planning Poker online: do jednoczesnego szacowania bez zakotwiczenia.
• Wirtualna tablica: do dekompozycji zadań i mapowania zależności.
• Wideokonferencja z trwałym czatem: trzymaj kanał czatu otwarty przez całą sesję.

Lista kontrolna gotowości do Sprint Planningu

Używaj tej listy przed każdą sesją Sprint Planningu.

• Product Backlog jest uporządkowany z wyraźnymi priorytetami dla historii odpowiadających 1,5× pojemność sprintu.
• Wszystkie kandydujące historie mają zaakceptowane kryteria akceptacji.
• Wszystkie kandydujące historie mają szacunki punktów historii.
• Dostępność członków zespołu jest potwierdzona.
• Pojemność sprintu jest obliczona i uzgodniona.
• Product Owner ma gotowy projekt Sprint Goala.

Powiązane poradniki i materiały

• Czym jest Sprint Planning w Scrumie?
• Szablon agendy Sprint Planning
• Przegląd planowania Scrum
• Poradnik Planning Poker
• Jak używać Planning Pokera krok po kroku
• Uruchom darmową sesję planning pokera