Wydarzenia Scrumowe #2 Sprint Planning

2 czerwca 2020 • 7 min to read

To już drugi artykuł w serii o Spotkaniach Scrumowych. Pomoże Ci zrozumieć wszystkie aspekty Sprint Planningu: jaki jest cel tego wydarzenia, jak ono wygląda i o czym warto pamiętać na takim spotkaniu.

Spis treści

Wstęp

*Ten artykuł został zaktualizowany na podstawie Przewodnika Po Scrumie z 2020 roku.

Moim ostatnim artykułem rozpoczęłam serię dotyczącą Spotkań Scrumowych i opisałam pierwsze spotkanie w Scrumie - Sprint. Jeśli jeszcze go nie przeczytałaś, zapraszam serdecznie do lektury, zanim zaczniesz ten post.

Dzisiaj chciałabym kontynuować serię opisując spotkanie, które inicjuje Sprint - Sprint Planning - Planowanie Sprintu.

Proszę weź pod uwagę, że niektóre elementy Sprint Planningu, które będę opisywać nie są wymienione bezpośrednio w Przewodniku po Scrumie. W związku z tym, będę używać przykłady często spotykanych praktyk, lub moich własnych doświadczeń.

Sprint Planning - definicja i długość

Każdy Sprint rozpoczyna się od spotkania, które nazywa się Sprint Planning, czyli planowanie Sprintu. Podczas tego wydarzenia, Zespół Scrumowy: Deweloperzy, Product Owner i Scrum Master wspólnie tworzą plan pracy na nadchodzącą iterację.

Spotkanie ma określony limit czasowy (podobnie jak wszystkie inne wydarzenia w Scrumie do maksymalnie 8 godzin na 1 miesiąc Sprintu. Oczywiście w przypadku krótszych Sprintów, ten czas jest odpowiednio dostosowywany.

Aby, pomóc Ci zrozumieć czym jest Sprint Planning, chciałabym kontynuować mają sportową analogię z poprzedniego artykułu. To spotkanie jest jak początek sprintu - (krótkodystansowego biegu). Jeżeli rozpoczniesz za szybko, przed sygnałem startowym, cały wyścig musi być zrestartowany z powodu falstartu. Z drugiej strony, jeśli zagapisz się i przeoczysz start biegu, może to zrujnować cały Twój bieg i rezultat końcowy.

Dokładnie tak samo jest w Scrumie. Zespół Scrumowy potrzebuje pracować razem, aby rozpocząć Sprint. Jeśli ktoś zacznie przed innymi, nie będzie przejrzystości i wpłynie to bardzo na cały Sprint. Dodatkowo, każde opóźnienia w starcie, nieporozumienia, niejasne wymagania mogą opóźnić Sprint i wpłynąć negatywnie na jego rezultaty.

Dlaczego?

Pierwsza część Sprint Planningu powinna być skoncentrowana na wyjaśnieniu “Dlaczego” przez Product Ownera. W Przewodniku po Scrumie jest ona wyjaśniona w ten sposób:

Product Owner proponuje, jak zwiększyć wartość produktu oraz jego użyteczność w bieżącym Sprincie. Następnie cały Scrum Team współpracuje nad sformułowaniem Celu Sprintu, który opisuje to, dlaczego dany Sprint jest wartościowy dla interesariuszy. Cel Sprintu musi zostać określony przed zakończeniem Sprint Planningu.

Ja dodałabym jeszcze do tego opisu wyjaśnienie szerszego kontekstu związanego z produktem:

• Jak następny Sprint wpłynie na tworzenie produktu?
• Jakie są zmiany z poprzedniego Sprintu, które wpłynęły na górną część Product Backlogu? Co musi być wzięte pod uwagę podczas Sprint Planningu?

Z mojego doświadczenia wynika, że dużo łatwiej pracuje się nad czymś, jeśli znamy szerszy kontekst i rozumiemy cel naszych działań. Oczywiście detale związane z każdym elementem pracy, powinne być wyjaśnione w Kryteriach Akceptacji, ale oprócz tego ważne jest, aby Zespół Scrumowy rozumiał cały obrazek.

Pomocne może się okazać przedstawienie przez Product Ownera tzw. Sprint Roadmap (Mapy drogi Sprintów - planu działania) oraz wyjaśnienie Celu Produktu. Lubię analogię związaną z mapą drogi, ponieważ wyobrażam sobie, że Zespół Scrumowy zaczyna razem podróż. Dużo łatwiej osiągnąć pierwszy cel, jeśli mniej więcej wiemy o kolejnych miejscach, do których idziemy. Nawiasem mówiąc, jest to inny rodzaj roadmapy niż używana w Zarządzaniu Projektami. Ta jest tylko pewnym szerokim kontekstem, wizją opartą na velocity (prędkości) zespołu i może być zmieniana, kiedy następują zmiany.

Następnym krokiem Sprint Planningu jest ustalenie Celu Sprintu przez Zespół Scrumowy. Jest to cel, który zamierzają oni zrealizować podczas najbliższej iteracji. Cel Sprintu powinien dostarczać wartość i być jasny dla każdego. Pomaga on zespołowi w skupieniu i w rozumieniu, dlaczego wykonują swoją pracę.

Co?

Po ustaleniu “Dlaczego” w Sprincie, czas na rozmowę o tym “Co” będzie zrobione w trakcie Sprintu. Właściciel Produktu i Deweloperzy dyskutują nad tym jakie elementy z Product Backlogu będą realizowane w obecnym Sprincie. Lista elementów wybranych do Sprintu to Sprint Backlog.

Jeżeli nie jest to pierwszy Sprint tego zespołu, powinni oni mieć jakieś informacje potrzebne do planowania Sprintu tj:

• Capacity - Przewidywana pojemność - liczba godzin, w których członkowie zespołu będą dostępni podczas Sprintu.
• Velocity - Prędkość zespołu w poprzednich Sprintach.
• Ich Definicja Ukończenia - w jaki sposób zespół wie, że jakiś element Backlogu jest ukończony.

To Deweloperzy decydują o tym ile elementów z Product Backlogu zostanie wybranych do Sprintu. Jest to jeden z pierwszych, ważnych momentów w Scrumie, kiedy to Product Owner musi zaufać im, że wybiorą właściwą ilość pracy bazując na swojej ekspertyzie i poprzednich doświadczeniach. Nikt nie wie lepiej ile pracy mogą wykonać Deweloperzy w trakcie Sprintu oprócz ich samych.

Jak?

Kiedy Deweloperzy wiedzą już jaki jest cel ich działań i zdecydowali co będzie zrobione, czas najwyższy, aby porozmawiać o tym jak to się stanie.

Sprawdźmy co o tym mówi Przewodnik po Scrumie:

Dla każdego wybranego elementu Product Backlogu Developerzy planują pracę niezbędną do wytworzenia Incrementu zgodnego z Definicją Ukończenia. Często odbywa się to w ten sposób, że elementy Product Backlogu dzielone są na mniejsze części możliwe do wykonania w ciągu maksymalnie jednego dnia. Decyzja o sposobie tego podziału należy wyłącznie do Developerów. Nikt inny nie narzuca im, jak przekształcić elementy Product Backlogu w wartościowe Incrementy.

Nie jest to tutaj wymienione, ponieważ wydaje się to sprawą oczywistą, ale Deweloperzy potrzebują zdecydować jak będą sprawdzać codziennie czy posuwają się we właściwym kierunku ze swoją pracą. Jak zamierzają sprawdzać swoją pracę, komunikować się ze sobą? Będą się spotykać codziennie na Daily Scrumie, ale co więcej?

Są pewne elementy techniczne, które moim zdaniem powinny być przedyskutowane:

• W jaki sposób będą sprawdzać postępy swojej pracy? Czy będą używać Tablicy Kanban? Jeśli tak, to czy zamierzają używać kolumn “Do zrobienia”, “W trakcie”, “Zrobione” czy też jakichś innych, które lepiej odzwierciedlają ich pracę?
• Czy chcą posługiwać się narzędziami takimi jak Sprint Burndown, Burnup, aby sprawdzić, czy przybliżają się do osiągnięcia Celu Sprintu?
• A co z Bugami? Czy będą je w ten sposób nazywać? A może w firmie obowiązuje inne słownictwo? Jak zamierzają sobie radzić z jakimikolwiek błędami/problemami w trakcie tworzenia produktu?
• Jak będzie wyglądała komunikacja w Zespole Scrumowym? Czy planują się komunikować tylko twarzą w twarz, a może będą używać maili, MS Teams, Zoom, czy też innej platformy?

Jest oczywiście możliwe, że będzie więcej aspektów technicznych, które wymagają przedyskutowania. Myślę, że jest ważne, aby porozmawiać o nich i mieć wspólne zrozumienie zarówno komunikacji, jak i współpracy. Nie musi to być długa dyskusja. Ważne, aby zakończyła się wspólnym zrozumieniem.

KIedy to wszystko jest już uzgodnione, Deweloperzy mogą zdecydować o rozmiarze poszczególnych elementów wybranych do Sprintu. Z mojego doświadczenia wynika, że może to być także część regularnego Backlog Refinementu. Istnieją różne sposoby estymowania pracy np. Planning Poker (przy użyciu ciągu Fibonacciego), estymowanie rozmiarami T-shirtów, Psów itp.

Głównym celem tej aktywności jest miejsce na wnikliwą dyskusję na temat konkretnych elementów backlogu oraz używanie estymat do kalkulowania Velocity. Może ono być świetnym narzędziem w trakcie planowania kolejnego Sprintu.

Jeśli już wszystko jest przedyskutowane, zrozumiałe i zaplanowanie, czas zabrać się do pracy. Gdyby Deweloperzy odkryli, że nie wybrali wystarczająco dużo elementów, albo wybrali za dużo, bądź są jakieś potrzebne zmiany, mogą to negocjować z Product Ownerem.

Podsumowanie

Najważniejsze rzeczy do zapamiętania:

• Scrum Team Deweloperzy , Product Owner i Scrum Master) powinni uczestniczyć w Sprint Planningu.
• Sprint Planning ma ograniczenie czasowe do max 8 godzin na miesięczny Sprint.
• Product Owner powinien wyjaśnić “Dlaczego?” Sprintu - jaka jest jego wartość, a cały Zespół Scrumowy tworzy na tej podstawie Sprint Goal - Cel Sprintu.
• PO i Deweloperzy dyskutują na temat tego, co może być wybrane do Sprintu, ale ostateczna decyzja jest po stronie Deweloperów.
• Wkładem do Sprint Planningu mogą być: przewidywane capacity, velocity, Definicja Ukończenia.
• Sprint Goall i Sprint Backlog są wynikiem Sprint Planningu
• To ważne, aby Deweloperzy przedyskutowali jak zamierzają pracować w trakcie Sprintu - wszystkie techniczne elementy: narzędzia, tablice, sposoby komunikacji.
• Deweloperzy mogą także estymować elementy Sprint Backlogu podczas tego spotkania (lub podczas Backlog Refinementu).