Sprint Planning Meeting: Definicja, przebieg i ważne wskazówki

Kickoff każdego Sprintu to Sprint Planning Meeting. Służy do ustalenia zakresu pracy zespołu Scrum na nadchodzący Sprint. W tym artykule przeczytasz, jak Sprint Planning Meeting musi być przygotowany przez Product Ownera, kto w nim uczestniczy, jak przebiega i na co zespół powinien zwrócić uwagę.

Sprint Planning: Cele i uczestnicy spotkania

Sprint Planning Meeting ma dwa cele. Po udanym Sprint Planningu:

• Product Owner i zespół developerski uzgadniają cel Sprintu (Outcome)
• i wspólnie stworzyli Sprint Backlog. Sprint Backlog zawiera wszystkie Product Backlog Items, które muszą być zrealizowane w Sprincie, aby osiągnąć cel Sprintu (Output).

Czasami Outcome i Output są podsumowywane jako MVP, Minimum Viable Product.

Kto zaprasza na Sprint Planning?

Product Owner zaprasza zespół developerski i Scrum Mastera na sesję Scrum Planning. Jeśli są też Interesariusze, którzy chcą zobaczyć, jaki jest cel Sprintu i które Backlog Items będą realizowane, Product Owner zaprasza też ich.

Przygotowanie Scrum Planning Meeting

Aby Product Owner i zespół developerski osiągnęli obydwa cele Planning Meeting, muszą być spełnione pewne warunki wstępne. Poniższe kroki przygotowawcze są zatem niezbędne przed Sprint Planningiem w Scrumie. Jeśli sam pracujesz jako PO lub aktualnie przygotowujesz się do roli Product Ownera, możesz skorzystać z tej listy kontrolnej lub z punktów wymienionych poniżej.

• Product Owner zdefiniował cel Sprintu (Outcome) i wybrał odpowiadające mu Product Backlog Items (PBIs).
• Wybrane PBIs zostały sformułowane z wystarczającą ilością szczegółów – najlepiej we współpracy z zespołem developerskim, np. w ramach Product Backlog Refinementu.
• Wybrane PBIs zostały uporządkowane w kolejności, w jakiej zespół developerski będzie je realizował. Wzięto pod uwagę zależności techniczne.
• Zespół posiada Definition of Done (DoD). Zapewnia ona wspólne rozumienie „kiedy coś jest gotowe".
• Ustalono pojemność zespołu na następny Sprint, np. uwzględniając średnią Velocity z ostatnich Sprintów i ewentualne planowane urlopy poszczególnych członków zespołu.

Przebieg Sprint Planningu

Jeśli Sprint Planning jest przygotowany jak opisano, możesz przystąpić z Twoim Scrum Teamem do właściwego przebiegu. Spotkanie przebiega według następującej Sprint Planning Agendy:

• Product Owner przedstawia cel Sprintu i odpowiadające mu PBIs oraz odpowiada na pytania zespołu. Cel Sprintu powinien być dobrze widoczny dla wszystkich członków zespołu, udokumentowany przy Sprint Backlogu.
• Jeśli PBIs nie zostały jeszcze oszacowane, teraz należy je oszacować. Jeśli szacowanie już miało miejsce, po szczegółowej dyskusji na temat realizacji Twój zespół może teraz doprecyzować szacowanie.
• Zespół składa Product Ownerowi i Interesariuszom prognozę, które PBIs dostarczy do końca Sprintu zgodnie z wspólnie opracowanym DoD. W ten sposób tworzy się Sprint Backlog, w którym powinno być udokumentowane, do których PBIs zespół developerski się zobowiązał i które będzie opcjonalnie dodatkowo realizował.

Oczywiście w Scrumie obowiązuje Time Box też dla Sprint Planningu: Długość Sprint Planningu nie powinna przekraczać jednego dnia (Time Box: 8 godzin).

Rozróżnienie na Sprint Planning 1 i 2

Nasza wskazówka praktyczna: Często Scrum Teamy rozróżniają między Sprint Planningiem 1 i 2:

• Sprint Planning 1 zajmuje się pytaniem: Co chcemy podjąć w nadchodzącym Sprincie?
• Sprint Planning 2 zajmuje się pytaniem: Jak chcemy to podjąć?

Time Box obu Planningów nie dzieli się przy tym na po 4 godziny – zamiast tego Planning 1 jest po dobrym Refinemencie automatycznie dość krótki, podczas gdy większa część Time Boxa potrzebna jest do Planningu 2.

Chociaż nie jest to obowiązkowe, niektóre zespoły developerskie w Scrum Sprint Planningu 2 dzielą Product Backlog Items na mniejsze pakiety pracy (Tasks). Ta druga część Sprint Planningu odbywa się często bez Product Ownera.

Co jeszcze powinien wziąć pod uwagę zespół przy planowaniu Sprintu?

Zespół developerski nigdy nie będzie mógł pracować w Sprincie wyłącznie nad wybranymi Sprint Backlog Items, ponieważ w każdym zwinnym środowisku pracy zdarzają się przerwy, małe nagłe wypadki i pilne prośby o wsparcie.

Z tego powodu warto, aby Twój zespół zaplanował w Sprintach pewien rodzaj bufora, który uwzględnia np. następujące czynności:

• Naprawianie problemów operacyjnych, np. gdy serwer się wyłącza
• Naprawianie krytycznych błędów
• First- lub Second-Level Tech-Support

Takie bufory zapewniają, że Scrum Sprint Planning wytwarza Backlog, który zespół jest w stanie rzeczywiście zrealizować, nie frustując się zakłóceniami. Ponadto nasze badania pokazują, że zespoły z buforem stają się z czasem bardziej wydajne. Wynika to m.in. z tego, że te zespoły częściej osiągają cele Sprintu i tym samym częściej doświadczają sukcesów.

Wyniki planowania Sprintu

Kiedy Ty i Twój zespół możecie oznaczyć następujące punkty jako wykonane, wiecie, że Wasze planowanie Sprintu było udane i zrobiliście wszystko prawidłowo:

• Scrum Team rozwinął wspólne rozumienie tego, co ma zostać osiągnięte w nadchodzącym Sprincie (cel Sprintu).
• Poprzez dyskusję zespołu developerskiego między sobą osiągnęliście wspólne rozumienie, jak poszczególne PBIs mają być zrealizowane.
• Stworzyliście starannie odwzorowany Sprint Backlog, który zawiera PBIs w kolejności Product Backlogu, ewentualnie nawet po rozbiciu na zadania, z odpowiadającymi im czynnościami.

Największy błąd podczas Sprint Planning Meeting

Niektóre zespoły developerskie za wszelką cenę starają się stworzyć doskonały Sprint Backlog, próbując identyfikować każde, nawet najdrobniejsze zadanie i szacować je z akrybią. Najczęściej dzieje się to, gdy kierownictwo jeszcze nie w pełni zrozumiało zwinny sposób pracy i żąda takich „dokładnych" szacowań.

Ponieważ przy nadmiernie dokładnym szacowaniu podczas Sprint Planning Meeting traci się zbyt wiele czasu, Scrum Master powinien zadbać o to, aby nie gubić właściwego celu Planningu: a mianowicie wybranie właściwych PBIs na następny Sprint i omówienie ich na tyle, aby zespół czuł się gotowy do realizacji Items.

Podsumowanie dotyczące Sprint Planning Meeting

Udane Sprint Planning Meeting stoi i upada z dobrym przygotowaniem, takim jak Product Backlog Refinement. Sprint Planning Meeting z kolei dostarcza warunków wstępnych do tego, aby każdy w zespole wiedział, co i jak ma być zrealizowane w następnym Sprincie. Jeśli więc Sprint ma się udać, a zespół developerski ma pomyślnie i bezstresowo realizować PBIs, w Scrumie Planning Meeting jest absolutnie niezbędny.