Sprint zaczyna się od długiej dyskusji, w której zespół próbuje zgadnąć, ile pracy się zmieści, ktoś bierze za dużo zadań "na zapas", a po tygodniu okazuje się, że połowa z nich i tak nie zostanie skończona. To typowy obraz źle prowadzonego Sprint Planning - spotkania, które powinno dawać zespołowi jasność, a w praktyce kończy się niedopowiedzeniami.
Dobrze przeprowadzone planowanie sprintu nie polega na wypełnieniu tablicy maksymalną liczbą zadań. Polega na wybraniu pracy, którą zespół realnie jest w stanie skończyć, i na wspólnym zrozumieniu, dlaczego akurat ta praca jest najważniejsza w danym momencie.
W tym artykule pokażę, jak przygotować się do Sprint Planning, jak prowadzić samo spotkanie krok po kroku i jakich błędów unikać, żeby planowanie nie zamieniało się w zgadywanie.
Czym jest Sprint Planning i jaki ma cel
Sprint Planning to spotkanie na początku sprintu, na którym zespół decyduje, jakie zadania z backlogu zrealizuje w nadchodzącej iteracji i jak zamierza to zrobić. Efektem powinny być dwie rzeczy: lista zadań na sprint oraz jasno określony cel sprintu - krótkie podsumowanie tego, co zespół chce osiągnąć, niezależnie od szczegółów poszczególnych zadań.
Cel sprintu jest często pomijany, a to on daje zespołowi możliwość podejmowania decyzji w trakcie sprintu - jeśli pojawi się nieoczekiwany problem, zespół wie, które zadanie można przesunąć, a które jest kluczowe dla celu i musi zostać zrobione.
Bez celu sprint staje się po prostu listą zadań do odhaczenia, a zespół traci możliwość elastycznego reagowania, gdy coś idzie inaczej niż planowano - każda zmiana wymaga wtedy pytania kierownictwa, co teraz jest ważniejsze.
Kto powinien uczestniczyć w planowaniu sprintu
W planowaniu powinien brać udział cały zespół wykonujący pracę, nie tylko lider czy Scrum Master. Osoby, które będą realizować zadania, najlepiej oceniają, ile pracy faktycznie się zmieści - decyzje podjęte bez nich kończą się planami, które zespół i tak ignoruje po dwóch dniach.
W większych zespołach, gdzie nie każda osoba musi być obecna przy każdym zadaniu, wystarczy, żeby na spotkaniu była przynajmniej jedna osoba znająca każdy obszar pracy, którego dotyczą planowane zadania.
Osoba odpowiedzialna za priorytety biznesowe - product owner albo kierownik projektu - powinna być dostępna, żeby odpowiadać na pytania o cel i kontekst zadań, ale nie musi decydować, jak dokładnie zadania zostaną wykonane.
Co przygotować przed planowaniem sprintu
Uporządkowany i wyestymowany backlog
Planowanie sprintu z nieuporządkowanym backlogiem zamienia się w sesję sortowania zadań, zamiast w planowanie pracy. Backlog powinien być uporządkowany według priorytetu jeszcze przed spotkaniem - więcej o tym, jak to robić, przeczytasz w artykule Zarządzanie backlogiem produktu - od chaosu do porządku. Zadania powinny mieć też wstępną estymację, najlepiej ustaloną zgodnie z metodami opisanymi w artykule Estymacja zadań w zespole - jak szacować czas realizacji.
Znana pojemność zespołu
Pojemność (capacity) to ile pracy zespół realnie jest w stanie wykonać w danym sprincie, uwzględniając urlopy, inne zobowiązania i historyczne tempo z poprzednich sprintów. Planowanie bez znajomości pojemności prowadzi do brania zbyt wielu zadań "bo się wydaje, że się zmieści".
Najprostszy sposób na ustalenie pojemności to spojrzenie na liczbę zadań albo punktów estymacji zrealizowanych w ostatnich dwóch lub trzech sprintach. Średnia z tego okresu jest dużo bardziej wiarygodna niż intuicja jednej osoby w dniu planowania.
Cel sprintu
Warto przyjść na spotkanie z propozycją celu sprintu, nawet w formie jednego zdania, żeby zespół miał punkt wyjścia do dyskusji, a nie zaczynał od zera.
Jak prowadzić Sprint Planning krok po kroku
Ustal cel sprintu
Zacznij od pytania: "co chcemy móc powiedzieć o tym sprincie na koniec, jeśli się uda?". Odpowiedź na to pytanie staje się celem sprintu i punktem odniesienia dla wszystkich decyzji podjętych później.
Wybierz zadania z backlogu
Zespół przegląda zadania z najwyższym priorytetem i sprawdza, czy wspierają ustalony cel. Zadania, które nie mają związku z celem sprintu, lepiej zostawić na później, nawet jeśli są wysoko w backlogu z innych powodów.
Sprawdź zależności i ryzyko
Przed zatwierdzeniem listy zadań warto zapytać, czy któreś z nich zależy od czegoś poza kontrolą zespołu - dostawcy, innego zespołu, decyzji klienta. Takie zależności warto oznaczyć i monitorować od pierwszego dnia sprintu, podobnie jak opisano w artykule Zarządzanie ryzykiem w projekcie.
Potwierdź zaangażowanie zespołu
Na koniec planowania każda osoba powinna potwierdzić, że lista zadań jest realistyczna z jej perspektywy. Jeśli ktoś ma wątpliwości, lepiej zmniejszyć zakres sprintu teraz, niż odkryć problem w połowie iteracji.
Przykład z praktyki
Zespół produktowy zaczynał każdy sprint od pytania "co się zmieści", patrząc tylko na listę zadań z najwyższym priorytetem. Po kilku sprintach, w których połowa pracy zostawała niedokończona, zespół zmienił podejście - zaczął od ustalenia jednego celu sprintu, na przykład "klient może samodzielnie wygenerować raport bez pomocy supportu", i wybierał tylko te zadania, które realnie do tego celu prowadziły.
Efekt: liczba zadań w sprincie spadła, ale liczba ukończonych sprintów w całości wzrosła. Zespół przestał kończyć iterację z listą "prawie zrobionych" zadań, które i tak trzeba było przenosić dalej.
Ile powinno trwać planowanie sprintu
Dla sprintu dwutygodniowego dobrym punktem odniesienia jest spotkanie trwające od jednej do dwóch godzin. Krótszy sprint, na przykład tygodniowy, wymaga proporcjonalnie krótszego planowania - długie planowanie krótkiego sprintu zjada nieproporcjonalnie dużo czasu względem samej pracy.
Jeśli planowanie regularnie trwa dłużej niż zakładano, to często sygnał, że backlog nie był wystarczająco uporządkowany przed spotkaniem, a nie że sprint jest szczególnie skomplikowany.
Dobrym testem jest pytanie zadane sobie tydzień przed planowaniem: czy wiadomo już, jakie zadania prawdopodobnie znajdą się na szczycie listy? Jeśli odpowiedź brzmi "nie mam pojęcia", backlog wymaga przeglądu zanim zespół usiądzie do wspólnego planowania.
Najczęstsze błędy podczas planowania sprintu
Planowanie bez celu sprintu - zespół wybiera zadania z listy, ale nie wie, co właściwie chce osiągnąć jako całość.
Ignorowanie pojemności zespołu - branie tyle zadań, ile zmieściło się "na oko", bez odniesienia do tego, co zespół realnie skończył w poprzednich sprintach.
Brak udziału osób wykonujących pracę - decyzje podjęte przez lidera bez konsultacji z zespołem, który potem i tak je koryguje.
Dodawanie zadań w trakcie sprintu bez usuwania innych - sprint, do którego cały czas coś dokłada, nigdy nie zostaje zrealizowany w całości.
Traktowanie planu jako sztywnej obietnicy - plan sprintu to najlepsze dostępne przewidywanie, nie kontrakt, którego naruszenie wymaga wyjaśnień przed całą firmą.
Jak Taskello pomaga w planowaniu sprintu
W Taskello sprint tworzy się jednym kliknięciem, a zadania z backlogu można przeciągnąć do niego metodą drag & drop, widząc na bieżąco, ile pracy już zostało zaplanowane. Po zakończeniu sprintu nieukończone zadania automatycznie przechodzą do następnego, więc zespół nie musi ręcznie przepisywać tego, co nie zostało zrobione.
Priorytety i estymacje przypisane do zadań są widoczne już na etapie wyboru zadań do sprintu, co przyspiesza dyskusję o tym, co faktycznie powinno znaleźć się w danej iteracji.
Podsumowanie
Dobry Sprint Planning zaczyna się przed samym spotkaniem - od uporządkowanego backlogu, znanej pojemności zespołu i przemyślanej propozycji celu sprintu. Samo spotkanie powinno kończyć się jasnym celem, realistyczną listą zadań i potwierdzeniem zaangażowania całego zespołu, nie tylko lidera.
Jeśli Twoje sprinty regularnie kończą się niedokończoną pracą, zacznij od jednej zmiany: zanim zaplanujesz następny sprint, sprawdź dokładnie, ile pracy zespół skończył w poprzednim. Ta jedna liczba mówi więcej o realnej pojemności zespołu niż jakakolwiek dyskusja na spotkaniu.
Jeśli chcesz dodatkowo sprawdzić, na co realnie ucieka czas Twojego zespołu między poszczególnymi planowaniami, sprawdź artykuł Zarządzanie czasem w zespole - praktyczne metody. A jeśli sprinty kończą się dobrze zaplanowane, ale wnioski z nich nigdzie nie trafiają, warto wrócić do artykułu Retrospektywa Scrum - jak przeprowadzać i wyciągać wnioski.