Sprint Planning – Twoja checklista

Planowanie sprintu (Planning) to jedno z 4 spotkań-ceremonii opisanych w Scrum Guide jako element framework’u. Podczas Planning’u ze szczytu Product Backlog’a wyłaniane są zadania, do realizacji których Zespół Deweloperski przystąpi w nadchodzącym sprincie. W jaki sposób usprawnić dyskusję? Oto gotowa recepta!


„Sprint to Sprint” i deweloperzy, tak jak sportowcy, aby osiągnąć dobry wynik, muszą go sprawnie rozpocząć. Sprint Planning to kick-off na kolejne 2 tygodnie pracy – jeśli zaczniemy go rozwlekle i bez konkretów, trudno będzie zespołowi ochoczo i z entuzjazmem zabrać za realizację zadań. Aby Planning był rzeczywiście spotkaniem rozruchowym, nadającym tempo już od pierwszych minut pracy, należy pamiętać (przynajmniej) o kilku rzeczach. Na sukces sprintu wpływ mają też zaangażowanie, motywacja i atmosfera na Planning’u – dlatego ważnym jest aby o każdy z tych elementów zadbać.

Jakie praktyki warto wykorzystać podczas spotkań planowania sprintu z moimi zespołami?

Oto checklista, która usprawni twój Planning:

  1. Pilnuj czasu

Planning jest ceremonią, na której spotyka się sporo osób (zespół deweloperski, Product Owner, zaproszeni interesariusze), każdy ma coś do powiedzenia i na pewno znajdą się wśród tego grona przynajmniej ze dwie osoby, które lubią podyskutować. Jeśli rozmowa się rozwleka, warto nałożyć sobie granice, np. maksymalnie 5 minut na jedno zadanie, po których przechodzimy do kolejnego. Do porzuconego zadania można wrócić na końcu i zdecydować, czy skoro wzbudziło tyle dyskusji, to czy jest gotowe na wzięcie do sprintu. Pamiętaj : „Keep it short”.

  1. Planuj

Planning, jak sama nazwa wskazuje, to spotkanie planujące a nie doprecyzowujące czyli backlog, zadania powinny więc być przygotowane wcześniej. Nie ma podczas planowania miejsca na wymyślanie nowych funkcji (oczywiście zdarzają się szczególne sytuacje, które tego wymagają, ale jeśli zostawiamy wymyślanie nowych zadań na Planning to z dużym prawdopodobieństwem wpędzimy się w niedoszacowanie zadań i późniejsze przepychanki w temacie zakresu). Na Planning’u przeglądamy więc gotową, spisaną, z uwzględnieniem priorytetu zadań, listę zadań w Product Backlog’u. Jeśli podczas Planning’u pojawi się pomysł na kolejne zadanie, należy je wpisać na koniec Produkt Backlog’u i zaplanować jego doprecyzowanie.

  1. Szacuj

Warto na Planning’u stosować Planning Pokera (jeśli estymujemy w Story Pointach) lub jakąkolwiek inną technikę szacowania, bo jest to sposób najłatwiej wyciągający na światło dzienne brak zrozumienia zakresu zadania/brak pomysłu na jego rozwiązanie. Jeśli widzisz, że szacunki poszczególnych członków zespołu różnią się znacząco od siebie, to znaczy, że albo ktoś ma świetny pomysł na rozwiązanie zadania (to ten z najniższą estymatą), albo któryś z deweloperów nie zdaje sobie sprawy z ryzyka, które dane zadanie za sobą niesie (to ten sam, z najniższą estymatą).

  1. Wyjaśniaj

Osoba moderująca spotkanie powinna mieć na uwadze, że jeśli zadania zostały wcześniej przeanalizowane i oszacowane, to podczas Planning’u należy każde zadanie ponownie streścić tak, aby mieć pewność, że wszyscy rozumieją go w ten sam sposób. Jeśli zespół ma problem ze streszczeniem celu, jaki należy w zadaniu osiągnąć, to jest to sygnał, że zadanie należy doprecyzować.

  1. Testuj

Warto podczas Planning’u określić kto i w jakim trybie będzie odbierał zadanie i zanotować tę informację na karcie zadania/w systemie, aby za kolejne 2 tygodnie nie było wątpliwości z kim powinny być ustalane szczegóły. Ewentualnie można zanotować kto ma najwięcej informacji dotyczących realizacji zadania.

  1. Sprawdź dostępność

Na początku planowania uwzględnij dostępność wszystkich członków zespołu deweloperskiego i weź ją pod uwagę podczas planowania. Dostępność oznacza też, że jeśli w sprincie zdarzą się urlopy to należy zaplanować tryb przekazania informacji/zadań kolejnej osobie. Pomoże to uniknąć sytuacji „nie skończył zadania i poszedł na urlop” czyli niekończącego się przechodzenia zadań urlopowiczów do kolejnego sprintu.

  1. Podziel zadania

Unikaj przypisywania poszczególnych zadań do deweloperów na Planning’u – osłabia to samoorganizację zespołu. To zespół ma zdecydować kto i kiedy zajmie się konkretnym zadaniem – nie nadgryzajmy ciastka zanim zrobimy się głodni.

  1. Skup się na wartości biznesowej

Jeśli zadanie wydaje się mieć małą wartość biznesową – Planning jest ostatnim dobrym momentem aby o tym porozmawiać.

  1. Ustal cel Sprintu

Podczas Planning’u warto ustalić jaki jest cel sprintu – ustalenie go ma głęboki wymiar motywacyjny dla zespołu. Celem sprintu nie jest zrealizowanie poszczególnych zadań, a aktywna odpowiedź na zdefiniowaną potrzebę biznesową. Jeśli wyznaczymy jasny cel sprintu, to nawet jeśli któreś z zadań nie zostanie zrealizowane, zespół nadal będzie mógł mówić o sukcesie wobec jakiejś wyższej wartości (poszczególne zadania w sprincie mogą się też zmieniać, cel sprintu sprawia też więc, że zespół czuje odpowiedzialność za jakiś większy kawałek, wybiegający ponad poszczególne, przypisane do konkretnych osób, zadania). Poprzez uzgodnienie celu sprintu zespół też wie, które zadania mają najwyższy priorytet (te, które aktywnie wspierają cel).

  1. Zastanów się KIEDY?

Podczas Planning’u nie ustalamy kolejności realizacji zadań – tzn. Klient, Product Owner, Interesanci czy Biznes muszą mieć świadomość, że nie można oczekiwać, że któreś zadania będą zrealizowane w przeciągu 3 kolejnych dni – jedyne, co zespół jest w stanie zapewnić, to realizacja zadań w perspektywie kolejnych 2 tygodni (czy jakiejkolwiek innej, wcześniej przyjętej długości sprintu);

  1. Komunikuj jasno

Podczas Planning’u warto ustalić lub potwierdzić, jeśli zostało to ustalone już wcześniej, w jaki sposób komunikujemy się w zadaniach (czy poprzez komentarz w systemie czy poprzez przypisane zadania, a jeśli telefonicznie, to gdzie szukać później wykonanych w tej formie ustaleń ).

  1. Określ odpowiedzialność

Na koniec Plannnig’u warto jest aby sam zespół potwierdził, że „to jest nasz sprint”, to działa jak potwierdzenie przejęcia ‚pałeczki’ w kwestii zamiany zadań w działające funkcje systemu;

  1. Motywuj

Namawiam Product Owner’ów do wykorzystania spotkania planującego sprint jako momentu motywacyjnego. To na Planning’u Product Owner przekazuje zespołowi wizję tego, co należy przez kolejne 2 tygodnie osiągnąć. To w końcu moment przedstawienia korzyści, jakie przyniesie realizacja właśnie wybranych do sprintu zadań.

  1. CHECK – Sprawdź!

Planning to spotkanie, które wymaga mocnej moderacji, podaję więc kilka pytań, które warto zadawać uczestnikom (albo samemu sobie – w głowie, sprawdzając czy idziemy w dobrą stronę):

– Czy dyskutowany temat ma szansę realizacji w kolejnych 2 tygodniach? Jeśli nie – umówmy się na kolejne spotkanie.

– Czy dyskutowany temat ma wpływ na to, jaką pracochłonność będzie miało zadanie? Jeśli nie – należy przenieść dyskusję na później.

– Czy  dyskutowany temat ma wpływ na to, czy zadanie znajdzie się w sprincie? Jeśli nie, ograniczmy dyskusję do minimum.

– Co TY o tym myślisz? Czyli aktywacja wszystkich uczestników spotkania – osoby milczące często nie milczą bez powodu, a jeśli bez powodu, warto z nimi porozmawiać o sensie uczestnictwa w planowaniu (w ostatecznym rozrachunku to długie spotkanie, po co się nudzić przez tyle czasu?).

– Czy tester będzie wiedział jak to testować? Często osoby akceptujące/testerzy potrzebują dodatkowych informacji do zawarcia w zadaniu – jest to najlepszy moment, aby o tym porozmawiać.

Jasna wizja celu sprintu współdzielona przez Product Ownera i Zespół, odpowiednie tempo spotkania oparte na konkretach oraz aktywne uczestnictwo zespołu w całym procesie to fundamenty Dobrego Sprint Planningu. Powyższe praktyki działają w moich zespołach całkiem sprawnie – zachęcam więc do spróbowania ich także u siebie!

Napisz do nas

Potrzebujesz więcej informacji lub jesteś zainteresowany współpracą z nami? Chętnie odpowiemy na każde pytanie. Zapraszamy do kontaktu!
Pola oznaczone * są wymagane.

Więcej na naszym blogu...

Zobacz wszystkie posty