Sprint Planning to jedyne wydarzenie scrumowe, które jest podzielone na trzy części. Zaskakujące, jak wiele osób o tym zapomina…
Proces Scrum został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Poniższy wpis uwzględnia zmiany wprowadzone w Podręczniku Scrum.
Sprint Planning w pigułce
Planowanie Sprintu to wydarzenie, które jak sama nazwa wskazuje, służy zaplanowaniu prac prognozowanych do realizacji w ciągu bieżącego Sprintu, które mają nas przybliżyć do osiągnięcia Celu Produktu. „Bieżącego”, bo między Sprint Retrospective z poprzedniej iteracji, a planowaniem obecnej nie ma czasu na odpoczynek ani na inne prace. „Prognozowanych”, bo nie jest to zobowiązanie zespołu, a jedynie szacunki oparte o dane historyczne i doświadczenie.
Timebox, czyli maksymalny czas trwania dla tego wydarzenia, to osiem godzin. Czy to nie za dużo? Osiem godzin dotyczy miesięcznych iteracji, a jak wiemy przeciętny Sprint jest krótszy o połowę. To już daje nam „tylko” (lub „aż”) cztery godziny na zaplanowanie najbliższych dwóch tygodni. Jak jednak opowiadaliśmy na naszym zwinnym kanale na YouTube, skuteczne planowanie da się przeprowadzić w 45 minut!
Sprint Planning podzielony jest na trzy części, a jego efektem są dwa namacalne produkty: Sprint Backlog i Sprint Goal. Warto pamiętać o obu tych artefaktach i sprawdzić, czy faktycznie są kompletne na końcu Planowania Sprintu.
Product Owner na Planowaniu
Na Planowanie Sprintu przychodzi cały Scrum Team, a więc zarówno Deweloperzy, Product Owner, jak i Scrum Master. Każdy ma na nim swoje miejsce i swoje zadania.
Niezwykle ważnym elementem mającym wpływ na sukces Planowania Sprintu jest odpowiedzialność Product Ownera za przygotowanie całego zespołu. To znaczy, że to PO ma za zadanie nie tylko przekazać wszystkim, co się szykuje na następny Sprint, ale także upewnić się, że są tego świadomi. Jednym z istotnych elementów tego przygotowania jest Product Backlog Refinement, a więc ciągły proces doskonalenia elementów Backlogu Produktu.
Scrum Master z kolei facylituje wydarzenie, służy pomocą i radą zarówno Deweloperom jak i PO w kontekście zwinnego planowania. Podpowiada, jak uwzględnić empiryzm w Scrum, a w szczególności w procesie planowania oraz dba o to, aby wszystkie trzy części wydarzenia przyniosły spodziewane rezultaty.
Planowanie Sprintu, część pierwsza: „Po co?”
„Why is this Sprint valuable?” – Scrum Guide
Pierwszy krok, jak to często bywa, jest najważniejszy. Aby skutecznie się zaplanować i wiedzieć, co planujemy musimy znać odpowiedzieć na pytanie „Po co?”. Niektórym z nas wydaje się, że wystarczy nam odpowiednio spriorytetyzowany Product Backlog i już będziemy wiedzieć, co mamy robić. Chyba nie do końca tak jest!
Po pierwsze, najważniejsze elementy Product Backlogu nie muszą stanowić spójnej całości, po wtóre ograniczenie planowania jedynie do wyciągnięcia elementów „z góry” nie ułatwia nam widzenia tego, co osiągniemy na samym końcu.
Aby przeciwdziałać robieniu losowych rzeczy z backlogu, które wcale nie tworzą spójnej i pięknej całości potrzebujemy Celu Sprintu. Miał on powstawać jako wynik Sprint Planningu, jednak po spędzaniu czasu nad zaplanowaniem mało kto pamiętał o tym małym szczególe na końcu. Aby ukonstytuować powagę wyznaczania celu i zadbać aby się to zadziało, od 2020 roku to w pierwszej kolejności mamy uzyskać informacje o biznesowym uzasadnieniu realizacji Sprintu, a następnie na tej podstawie wybrać jego cel. Aby zadość uczynić powyższemu, Product Owner, jako Właściciel Produktu rozpoczyna planowanie proponując „jak zwiększyć wartość produktu oraz jego użyteczność”.
Cały Scrum Team, jako Zespół, definiuje Cel Sprintu, którego realizacja spowoduje zwiększenie wartości Produktu w kierunku wskazanym przez Product Ownera i Cel Produktu. Ten sprytny zabieg powoduje, że Scrum Team od razu dowiaduje się po co realizujemy Sprint, jaka będzie z niego korzyść i co wartościowego osiągną interesariusze.
Zespół Scrumowy ma teraz czas do końca planowania, aby zdefiniować Cel Sprintu, który wizję Product Ownera będzie realizował i będzie stanowił krok w kierunku Celu Produktu.
Planowanie Sprintu, część druga: „Co?”
„What can be delivered in the Increment resulting from the upcoming Sprint?” – Scrum Guide
W drugim kroku Deweloperzy muszą zdecydować, ile pracy są w stanie wykonać w ciągu najbliższej iteracji. Idąc od szczytu Backlogu omawiają z Product Ownerem kolejne wymagania, w szczególności to, jak się one mają do Celu Sprintu i czy jeszcze się zmieszczą w przewidzianym czasie.
To nie jest jednak miejsce na Product Backlog Refinement! Jeżeli jakieś wymaganie nie jest zrozumiałe przez absolutnie wszystkich, powinno zostać odłożone z powrotem do Backlogu Produktu. Na planowaniu ma nic gorszego, niż zagłębianie się w analizę User Stories, o którym prawie nic nie wiemy. Nie tylko stracimy czas, ale i skupienie uczestników spotkania.
W przypadku nacisków ze strony PO, to członkowie zespołu lub Scrum Master powinni jasno i wyraźnie powiedzieć, że zaplanowanie prac wymagania w którym jest zbyt wiele niewiadomych może zagrozić zrealizowaniu wszystkich prac. Skoro nie wiemy co robimy, to i nie możemy wiedzieć ile nam to zajmie.
Warto mieć pod ręką Product Backlog, ostatni Inkrement oraz historyczne i spodziewane Velocity zespołu. Wszystko to po to, żeby ułatwić członkom zespołu, którzy będą te prace wykonywać, decyzję o tym „ile wziąć na Sprint”.
To Deweloperzy decydują o tym, co finalnie trafi do Sprint Backlogu i nikt nie może wpłynąć na ich decyzję. Jednak należy też pamiętać, że to cały Scrum Team, wraz z Product Ownerem i Scrum Masterem, tworzą Sprint Goal.
Planowanie Sprintu, część trzecia: „Jak?”
„How will the work needed to deliver the Increment be achieved?” – Scrum Guide
Wydawałoby się, że po ustaleniu „co robimy”, wszystko jest już jasne i można zabierać się do pracy. Nie tak szybko! Zostało jeszcze potwierdzenie, że wszystko co zaplanowaliśmy ma szansę zmieścić się w Sprincie i upewnienie się, że wiemy jak zabrać się do każdego zadania. Co ważne, chcemy wiedzieć jak zacząć i mieć ogólny plan na zrealizowanie danego wymagania, ale nie musimy wiedzieć wszystkiego.
W trzecim kroku planowania, pokazujemy, że wiemy jak zrealizować to, co wybraliśmy do realizacji w kroku drugim. Deweloperzy zwykle rozpisują wymagania wrzucone do Sprint Backlogu na mniej lub bardziej szczegółowe zadania. Dla niektórych będziemy rozpisywać szczegółowe „taski„, a dla innych wystarczy nam spisanie ogólnego planu.
Jak bardzo powinniśmy wchodzić w detale? Nic nikomu do tego! Zespół jest samozarządzający i jako taki sam decyduje, jaki poziom szczegółowości jest wystarczający. Zazwyczaj praca na pierwszych kilka dni rozpisywana jest w taki sposób, żeby można było bez problemu podzielić się zadaniami, a im dalej tym bardziej przypomina to szkic. Chociaż są i takie zespoły, gdzie każda godzina każdej osoby jest uwzględniona w planie, ale trochę kłóci się to z agile mindsetem i scrumowym podejściem, gdzie mówimy, że szczegóły poznamy w trakcie pracy.
Jak mówi Scrum Guide, na koniec planowania Zespół Deweloperski powinien być w stanie opowiedzieć Product Ownerowi, w jaki sposób mają zamiar osiągnąć Cel Sprintu i zbudować Inkrement. Nie znaczy to, że mają od razu rzucać nazwami klas i mówić w którym pliku i która linia ulegnie zmianie, ale niedopuszczalne jest też, gdy zespół odpowiada, że „jakoś da radę”. Musimy wiedzieć, jak w ogóle zabrać się do realizacji każdego wymagania. Jeżeli tego nie wiemy, to nie powinno ono w ogóle znaleźć się w Sprint Backlogu. A tak naprawdę, nie powinno w ogóle trafić na Sprint Planning.
Sprint Planning w praktyce
W praktyce Sprint Planning jest często trochę mniej uporządkowany, niż by wynikałoby to z powyższego opisu. Owszem, zwykle najpierw ustalamy „po co”, następnie „co”, aby finalnie przejść do „jak” i utworzyć zadania (lub podzadania), które trafią do Sprint Backlogu. Na koniec jednak może okazać się, że jest ich za dużo lub za mało.
W takim przypadku wracamy do punktu pierwszego, gdzie Deweloperzy negocjują z Product Ownerem zakres zaplanowanych prac. Pamiętajmy, że Sprint Backlog to oszacowanie, a nie zobowiązanie. Dobrze by było, gdyby wszystkie elementy z tej listy zostały ukończone, ale tak naprawdę najbardziej zależy nam na osiągnięciu Celu Sprintu. Dlatego też tak ważna jest rozmowa na linii Deweloperzy – PO.
Przyda się ona także w kwestii wyboru wymagań z Backlogu Produktu. W teorii, jest to lista uporządkowana i powinniśmy wybierać elementy od góry, aż do momentu w którym uznamy, że więcej nie damy rady zrealizować. W praktyce jednak czasami warto przeskoczyć kilka wymagań i zrealizować jakieś potencjalnie mniej istotne, żeby ułatwić późniejsze prace lub zadbać o jakość. Takie decyzje nie są niczym wyjątkowym, ale trzeba pamiętać, że zawsze odbywają się w porozumieniu z Product Ownerem.
To pokazuje też, że nie da się uniknąć dyskusji o kolejnych iteracjach, zwłaszcza jeżeli odkładamy jakieś wymaganie „na później”. Pamiętajmy jednak, że planujemy tylko i wyłącznie najbliższy Sprint. Często pojawia się pytanie „Dlaczego nie dzielimy backlogu na Sprinty?” Odpowiedź jest prosta: zbiór wymagań żyje i zarówno jego zawartość, jak i kolejność zmienia się po każdym ukończonym Sprincie. Nie mamy gwarancji, że nic w naszym otoczeniu się nie zmieni, nie możemy też być pewni, że na pewno uda nam się zrealizować to, co sobie założyliśmy.
Może i nasz plan „na kolejny Sprint” jeszcze byłby ok, ale już wybieganie trzy-cztery iteracje do przodu po prostu się nie sprawdza. Przez taki czas zbyt wiele się zmieni, nasz plan wyląduje w koszu, a czas poświęcony na jego przygotowanie będzie stracony.
Szczegółowe Planowanie Sprintu
Powiedzieliśmy, że niektóre zespoły rozpisują wszystkie wymagania na szczegółowe zadania już na Sprint Planningu. Zwykle szczegóły realizacji zadań odkrywamy dopiero w trakcie prac realizowanych w Sprincie. W Scrumie, przed rozpoczęciem Sprintu, nie mamy przecież gotowej i kompletnej analizy. Wiemy „jak” będziemy podchodzić do każdego wymagania, ale szczegóły poznamy dopiero wraz z postępem prac.
Jeżeli jednak mamy szczegółową wiedzę na temat sposobu realizacji zadań, a także czas i miejsce, to możemy zaryzykować zwinny eksperyment. Rozpiszmy na Planowaniu Sprintu wszystkie zadania, jakie naszym zdaniem będą składały się na realizację każdego z wymagań. Rezultat tego eksperymentu powie nam, czy warto określać takie szczegóły już na planowaniu. Nie da się ukryć, że aby to osiągnąć, musimy mieć pewność, że sposób realizacji wymagań się nie zmieni. O dziwo, są takie miejsca i takie zespoły, że okaże się, że takie działanie jak najbardziej ma sens!
W podobny, empiryczny sposób próba zrealizowania uzgodnionego zakresu powie nam o tym, czy zaplanowaliśmy za dużo czy za mało. Oczywiście może nam w tym pomóc Velocity, trzeba jednak pamiętać, że szacunki wielkości zadań wyrażone w postaci np. Story Points nie są precyzyjne. Liczy się przede wszystkim doświadczenie.
Skalowanie Sprint Planning
Scrum działa idealnie dla jednego zespołu, a bardzo dobrze – dla dwóch. Później zaczynają się problemy. W przypadku spotkania Sprint Planning z pomocą przychodzi sam Scrum Guide i podział planowania na trzy części.
Jeżeli kilka Zespołów Scrumowych pracuje na jednym Backlogu Produktu, to sprawa jest bardzo prosta. Pierwsze dwie części spotkania czyli „po co” i „co” realizujemy wspólnie, dzieląc wymagania między poszczególne zespoły, aż wszystkie powiedzą „dość”. Absolutnie kluczowy okaże się tutaj dobrze przygotowany backlog. Bez niego nie mamy żadnych szans.
Na trzecią część Planowania Sprintu zespoły zwykle rozchodzą się i realizują je jak na samoorganizujące się jednostki przystało – osobno. Tutaj co prawda problemem może być dostępność Product Ownera, który jest tylko jeden na kilka zespołów, ale zwykle nie przeszkadza to aż tak bardzo. Istnieją też sposoby, żeby tę dostępność zwiększyć (patrz np. Proxy Product Owner).
Jeszcze więcej komplikacji pojawia się w dużych organizacjach, gdzie mamy do czynienia np. z Release Planningiem. To jednak jest tematyka, którą poruszamy w innych tekstach na naszym zwinnym blogu, oraz oczywiście na szkoleniach Scrum.
W przypadku innych konfiguracji, wielu Product Ownerów, kilku backlogów, masy zależności i rosnącej wielkości projektu, sprawy się nieco komplikują. Jeżeli jesteś tym zainteresowany lub zastanawiasz się jak skalować pozostałe wydarzenia scrumowe, role i jak uniknąć pułapek związanych ze zwiększającą się liczbą zespołów, skorzystaj z naszych warsztatów Skalowanie Scrum.
