Planowanie działań jest ważne – to wie chyba każdy. W Scrum planujemy sprinty, ustalamy w zespołach co będzie do wykonania w kolejnej iteracji. Ale najważniejsze jest to, że mamy ku temu jakiś cel. Jest nim Cel Sprintu, o którym Patrycja już wspominała w swoim artykule o Backlogu Sprintu. W tym tekście zajmiemy się całym procesem planowania!
Planowanie Sprintu wg Scrum Guide
Ile trwa i kiedy się odbywa?
Jak wszystkie wydarzenia w Scrumie, również Planowanie Sprintu jest ograniczone w czasie. Jego długość dla miesięcznego sprintu to 8 godzin. Proporcjonalnie dla sprintu, który trwa tydzień, planowanie nie powinno zajmować więcej niż 2 godziny. Podobnie jak to jest w przypadku Daily Scrum, Scrum Master pilnuje tego czasu. Oczywiście, spotkanie możemy skończyć wcześniej, pod warunkiem, że jego cele zostaną osiągnięte.
Jaki jest cel spotkania i kto w nim uczestniczy?
Bez tego wydarzenia nie byłoby w Sprincie miejsca na wyznaczenie elementów Backlogu Produktu jakie znajdą się w Backlogu Sprintu, no i nie wiedzielibyśmy jaki jest Cel Sprintu. W przewodniku znajdujemy informację, że to wydarzenie powinno dać nam odpowiedź na dwa pytania:
- Co może zostać dostarczone w ramach Przyrostu mającego być rezultatem nadchodzącego Sprintu?
- W jaki sposób praca, niezbędna do dostarczenia Przyrostu, będzie wykonana?
Odpowiadając na nie, spełniamy cel jaki niesie ze sobą Planowanie Sprintu. Dzięki tym pytaniom, przebieg spotkania można łatwo podzielić na dwie części: co możemy wykonać i jak to zrobimy. Temu wszystkiemu przyświeca Cel Sprintu, który często definiuje co będziemy robić w sprincie. Do jego osiągnięcia potrzebna będzie realizacja wyznaczonych do Sprint Backlogu zadań, więc oba te elementy są ze sobą ściśle powiązane. Należy jednak pamiętać, że Scrum Guide jasno mówi o tym, że celem może być także coś, co nie jest bezpośrednio odzwierciedlone w zadaniach, a jedynie sprawia, że Zespół Deweloperski pracuje razem nad spójnością i dodawaniem wartości do produktu.
W pierwszej części spotkania do określenia są Cel Sprintu i elementy Backlogu Sprintu, które doprowadzą Zespół do osiągnięcia wyznaczonego celu. W rozmowach o zakresie należy wziąć pod uwagę wiele czynników, tj. efekty minionej iteracji oraz założenia na kolejne, możliwości Zespołu Deweloperskiego, prędkość pracy, ewentualne nieobecności i inne wydarzenia mogące mieć wpływ na przebieg prac.
Gdy wiemy już co chcemy zrobić, ile elementów jest do wykonania i jaki przyświeca nam cel, należy przyjrzeć się jak doprowadzimy do tego, że wszystkie zadania zostaną zakończone (zgodnie z Definicją Ukończenia) w czasie nowego Sprintu. Podczas planowania Zespół Deweloperski powinien szczegółowo omówić pierwsze dni swojej pracy, tak by uzyskać wiedzę, czy wybrane elementy są możliwe do realizacji i w jaki sposób zostaną wykonane. Przy tego typu dyskusjach nieocenione jest wsparcie Product Ownera, który wyjaśnia założenia biznesowe i pomaga Zespołowi zrozumieć stojące za nimi dane, oczekiwania czy inne cele.
Po takim ćwiczeniu Planowanie Sprintu może zostać zakończone, a praca w nowym Sprincie rozpoczęta! Droga do realizacji Celu Sprintu weryfikowana jest na każdym Daily Scrumie.
Kto jest odpowiedzialny za przebieg spotkania?
Na strażnika Planowania Sprintu Scrum Guide wyznacza Scrum Mastera – musi on zadbać, by spotkanie się odbyło, a jego cele zostały spełnione. To, co ma być zrobione to decyzja Product Ownera, zaś jak to zrealizować należy już do Zespołu Deweloperskiego. Cały Zespół Scrumowy pracuje nad tym, by ustalić jak będzie wyglądał kolejny Sprint i jak wszyscy dojdą do osiągnięcia jego celu.
Biorąc pod uwagę te elementy, można powiedzieć, że za spotkanie odpowiedzialny jest cały Zespół Scrumowy. Każdy ma tu coś do powiedzenia, każdy wnosi jakąś wartość.
Jakie korzyści daje Planowanie Sprintu?
Bez planowania ciężko wyobrazić sobie ustalenie zakresu kolejnej iteracji. Główną korzyścią jest to, że cały Zespół Scrumowy może porozmawiać o aktualnych okolicznościach towarzyszących wytwarzaniu produktu. A co najważniejsze – reagować na sytuację od razu. Bez tego, przejście przez wymienione wyżej etapy staje się prawie niemożliwe. Wiemy też, że bez nich nie zaplanujemy właściwie pracy do wykonania w sprincie.
Teoria kontra praktyka
W teorii, wszystko wydaje się proste i klarowne. Każdy ma swoje zadanie, wykonujemy je i wszystko idzie gładko. W praktyce sytuacja komplikuje się, szczególnie wtedy, gdy członkowie Zespołu nie wiedzą co jest wynikiem takiego spotkania.
Zespół Deweloperski sam, bez konsultacji wyznacza zakres kolejnego Sprintu
Zdarza się, że Zespół Deweloperski samodzielnie wyznacza zadania do nowej iteracji. Nie ma nic w tym złego, dopóki Product Owner wie skąd wynika taki porządek i zgadza się to z biznesowymi założeniami Celu Sprintu. Błędne podejście ma miejsce wtedy, gdy zespół nie bierze pod uwagę maksymalizacji wartości wychodzącej wprost z biznesowych założeń i od użytkowników produktu. Samo wyznaczenie zadań np. “bo są fajne i łatwe” lub “wszystkie są techniczne bo czas na refaktor” nie wnosi nic do produktu, a jest to nadrzędne w przypadku pracy nad nim. Cały Zespół Scrumowy powinien brać pod uwagę stan i potrzeby wynikające z rozwoju produktu. Całością tego procesu powinien kierować Product Owner. To właśnie jego zadaniem jest dbanie o wartość wytworzonego przyrostu.
Product Owner wyznacza konkretne zadania, lecz nie wyznacza celu
Pomimo ciągłej pracy nad wartością produktu, Product Ownerzy często działają mocno na zadaniach. Zrealizowanie dużej ich ilości potrafi stać się celem i wyznacznikiem jakości pracy, co oczywiście jest złą praktyką. Zespół Scrumowy musi znać cel tego co robią. Co więcej, im bardziej Zespół Deweloperski jest świadomy z jakiego powodu te a nie inne zadania są wykonywane, te a nie inne cele wyznaczane, tym bardziej przykłada się do właściwych działań w ich kierunku. Znając tło, cele i oczekiwania, członkowie zespołów wiedzą dokąd zmierzają i mogą kreatywnie wspierać budowanie produktu.
Tak więc wyznaczenie zadań to za mało. Potrzebna jest współpraca, dzielenie się wiedzą i założeniami biznesowymi. W efekcie takich działań Zespół Scrumowy będzie w stanie pracować na najwyższych obrotach.
Zespół Deweloperski nie zastanawia się jak osiągnie Cel Sprintu
Bez zastanowienia się jak wyznaczony cel będzie realizowany, możemy zajść w ślepą uliczkę. Z doświadczenia wiem, że druga część Planowania Sprintu jest często pomijana, bo zdaje się być oczywista. Przecież Zespół Deweloperski omawiał już zadania w procesie refinementu, wie jaki jest cel, więc czego więcej chcieć? Problem tkwi w szczegółach! W bieżących okolicznościach dane zadanie może okazać się niemożliwe do wykonania, bo np. zaplanowane są urlopy, prace utrzymaniowe etc. Zawsze należy spojrzeć na pierwsze dni sprintu, zastanowić się co może być wykonane jako pierwsze i jak to wpłynie na realizację Celu Sprintu. Planowanie Sprintu ma na końcu dać każdemu członkowi zespołu pewność, że osiągnięcie Celu Sprintu jest możliwe. W drugiej kolejności wiemy jak to zrobić, prawie dzień po dniu.
Podsumowanie
Planowanie Sprintu to kluczowy moment w Sprincie. Bez niego cały Zespół Scrumowy miałby trudność z podjęciem działań w kolejnych iteracjach, a wizja i wartość produktu byłyby ciężkie do wdrożenia. To spotkanie wymaga wysiłku każdego. Scrum Master facylituje i dba o osiągnięcie celu spotkania, a Product Owner przedstawia wizję i założenia dla produktu, dzieli się wiedzą biznesową. Zespół Deweloperski przekuwa to wszystko w konkretne kroki do podjęcia w nadchodzących dniach. Planowanie pozwala także urzeczywistniać filary Scruma (inspekcja, adaptacja, transparentność) – każdy z nich musi być tu zastosowany!
Sprawdź nasze poprzednie wpisy:
