Planowanie Sprintu
Planowanie Sprintu (ang. Sprint Planning) rozpoczyna Sprint poprzez przygotowanie planu pracy do wykonania w Sprincie. Plan ten jest efektem wspólnej pracy całego Zespołu Scrumowego.
Właściciel Produktu zapewnia przygotowanie uczestników do omówienia najważniejszych elementów Rejestru Produktu oraz tego, jak powinien zostać sformułowany Cel Produktu. Zespół Scrumowy może zaprosić na Planowanie Sprintu również inne osoby jako doradców.
Planowanie Sprintu to spotkanie, w trakcie którego uczestnicy podejmują następujące tematy:
Dlaczego ten Sprint ma wartość?
Właściciel Produktu proponuje sposób zwiększenia wartości produktu oraz jego użyteczności w bieżącym Sprincie. Cały Zespół Scrumowy współpracuje następnie nad utworzeniem Celu Sprintu, który określi sposób zwiększenia wartości dla interesariuszy w bieżącym Sprincie. Cel Sprintu musi zostać określony przed zakończeniem Planowania Sprintu.
Co może zostać Ukończone w tym Sprincie?
Współpracując z Właścicielem Produktu Deweloperzy wybierają elementy Rejestru Produktu, nad którymi będą pracować w bieżącym Sprincie. Podczas tego procesu Zespół Scrumowy może uszczegółowić te elementy, co zwiększy ich zrozumienie oraz zwiększy prawdopodobieństwo ich realizacji.
Wybór zakresu pracy możliwej do realizacji w Sprincie może nie być łatwy. Im większy jest zakres wiedzy Deweloperów zgromadzony podczas ich dotychczasowej pracy, zrozumienie zadań do wykonania oraz Definicji Ukończenia, z tym większą pewnością będą oni mogli zaplanować realizację pracy w Sprincie.
W jaki sposób zostanie wykonana praca?
Dla każdego wybranego elementu Rejestru Produktu Deweloperzy planują pracę niezbędną do wytworzenia Przyrostu zgodnego z Definicją Ukończenia. Zwykle odbywa się to w ten sposób, że elementy Rejestru Produktu dzielone są na mniejsze części (zadania) możliwe do realizacji w maksymalnie jeden dzień. Decyzja o sposobie tego podziału należy wyłącznie do Deweloperów. Nikt inny nie może narzucić im, jak sposobu przekształcenia elementów Rejestru Produktu w wartościowy Przyrost.
Cel Sprintu, elementy Rejestru Produktu wybrane do realizacji podczas Sprintu oraz plan ich wykonania razem składają się na Rejestr Sprintu.
Ramy czasowe Planowania Sprintu to maksymalnie osiem godzin dla miesięcznego Sprintu. W przypadku Sprintów o mniejszej długości, spotkanie to trwa zwykle krócej.
Dobre praktyki planowania
Założeniem Planowania jest w pełni funkcjonalny produkt na koniec Sprintu. Planowane przez Was Elementy Rejestru Produktu powinny mieć wartość biznesową, bo dlaczego inaczej byłby sens je realizować. Dlatego Plan Sprintu nie będzie zawierać realizacji jedynie części Elementu – np. samo kodowanie bez testowania.
Gdy rozumiemy już, co chcemy zrobić, jak wiele elementów jest do wykonania i jaki mamy przed sobą cel, powinniśmy przyjrzeć się jak doprowadzimy do tego, że wszystkie zadania zostaną zakończone (zgodnie z Definicją Ukończenia) w czasie nowego Sprintu. Podczas Planowania Deweloperzy powinni szczegółowo omówić pierwsze dni swojej pracy, tak by uzyskać wiedzę, czy wybrane elementy są możliwe do wykonania i w jaki sposób zostaną zrealizowane. Przy tego typu dyskusjach ważne jest wsparcie Właściciela Produktu, który wyjaśnia założenia biznesowe i pomaga Zespołowi zrozumieć stojące za nimi cele, oczekiwania czy inne dane.
Mniej znaczy więcej
Sensowniej jest zaplanować mniej i dostarczyć więcej. Gdy zaplanowane zostanie zbyt wiele – prawdopodobnie nie uda się tego zrealizować. Zespół, który może dostarczyć osiem elementów i zaplanuje sobie dwanaście, prawdopodobnie dostarczy tylko cztery, albo pięć. Pozostałe będą rozgrzebane, czyli „w trakcie”. Dlatego lepiej jest zaplanować mniej i zostawić bufor na różne nieprzewidziane problemy. Można przecież ewentualnie dobrać dodatkowe Elementy Rejestru Produktu w trakcie trwania Sprintu.
Lepiej nie przypisujcie zadań do konkretnych osób w trakcie planowania. Zachowanie w stylu „moje, bo zaklepałem” często pojawia się u zespołów zaczynających pracę w Scrumie. Skutkiem takiego działania jest zaniechanie pracy zespołowej na rzecz zajmowania się tylko swoimi zadaniami. To oddala Zespół od realizacji Celu Sprintu. Może też powodować szukanie winnych, gdy realizacja się nie powiedzie.
Elementy Rejestru Produktu powinny być niewielkie. Od jednego do dwóch dni pracy całego Zespołu. W przeciwnym przypadku może się okazać, że gdy zaplanowany element zajmie więcej czasu, w Sprincie nie uda się dostarczyć nic. A plan zakładał uzyskanie przyrostu produktu. Przegląd Sprintu raczej nie będzie wówczas okazją do triumfowania.
Kto jest odpowiedzialny za przebieg spotkania?
To Scrum Master jest strażnikiem podczas Planowania – jego rolą jest sprawić, aby spotkanie się odbyło, a jego cele zostały zrealizowane. To, co ma być zrobione to decyzja Właściciela Produktu, zaś jak to zrobić należy już do Deweloperów. Cały Zespół Scrumowy pracuje nad tym, by uzgodnić jaki będzie kształt kolejnego Sprintu i jaki jest plan dotarcia wspólnie do celu.
Rejestr Produktu musi być dobrze uporządkowany. Dlatego w poprzednim Sprincie należy zadbać o Doskonalenie Rejestru. Elementy na jego szczycie mają być Gotowe (Ready) do implementacji. Nie oznacza to „opisane w 100%”, część szczegółów można ustalić już podczas trwania Sprintu. Ale, gdy Właściciel Produktu nie ma pojęcia jakie są priorytety, ani co trzeba zrobienić, to Planowanie Sprintu będzie długie i trudne. Oczywiście na przygotowanie Backlogu macie czas w trakcie Porządkowania.
Plan Sprintu to praca dla Zespołu i to on jest odpowiedzialny za jego uzgodnienie. Dlatego tylko Deweloperzy decydują jak dużo mogą zrobić w trakcie Sprintu. Ani Właściciel Produktu, ani żaden inny interesariusz nie może wymuszać poszerzenia zakresu Sprintu. Rolą Właściciela Produktu jest zaś ustawienie kolejność Elementów w Rejestrze Produktu. Scrum Master pomaga Zespołowi stworzyć plan możliwy do realizacji i chroni go przed zewnętrzną presją.
Analizując wszystkie elementy, można rzec, że za to wydarzenie odpowiedzialny jest cały Zespół Scrumowy. Każdy ma tu coś do wniesienia, każdy daje jakąś wartość.
Podsumowanie
Planowanie Sprintu to bardzo ważny moment w Sprincie. Bez dobrego Planowania cały Zespół Scrumowy miałby trudność z podjęciem działań w kolejnych iteracjach, a wartość, wizja produktu i jego cel byłyby trudne do wdrożenia. To wydarzenie jest wysiłkiem każdego. Scrum Master facylituje i dba o osiągnięcie jego celu, Właściciel Produktu przedstawia wizję i założenia dla produktu, dzieli się wiedzą biznesową, Deweloperzy przekuwają to wszystko w konkretne kroki do wykonania w kolejnych dniach. Planowanie urzeczywistnia filary Scruma (inspekcję, adaptację i transparentność) – każdy z nich ma tu swoje miejsce.
Planowanie Sprintu to praca całego Zespołu Scrumowego, w jej wyniku powinien powstać plan realizacji Celu Sprintu. Kilka wymienionych powyżej porad może być pomocnych, jeśli chcesz wesprzeć Zespół w lepszej organizacji Planowania Sprintu.
Literatura:
Gowin E., „Planowanie Sprintu”,Agile247.pl, 2018;
McGreal D., „Effective Sprint Planning”, Scrum.org, 2018;
Rogala B., „Planowanie Sprintu, czyli czas na ustawienie kierunku”, AgileHunters.com, 2020;
Schwaber K., Sutherland J., „Przewodnik po Scrumie”, Scrum.org, 2020;
Vivify, „5 Tips for Effective Sprint Planning”, VivifyScrum.com, 2018;
Wieczorek J., „5 porad, jak przeprowadzić udane Planowanie Sprintu”, Agile 247.pl, 2020;
Wieczorek J.,Szczepanik J., „Porządny Agile #13 – Porządne Planowanie Sprintu”, PorządnyAgile.pl, 2019;
Wykowski T., „Jak może wyglądać planowanie Sprintu?”, Procognita.pl, 2018.