W tym artykule Dave West, dyrektor generalny Scrum.org, przedstawia wydarzenie planowania sprintu opisane w witrynie Scrum.org. Scrum.org uczy Scrum w oparciu o Przewodnik Scrum uważany za oficjalny przewodnik po ramach postępowania Scrum w świecie Agile. Poniżej Megan Cook z Atlassian dzieli się swoim spojrzeniem na planowanie sprintów w tym filmie:
Czym jest planowanie sprintu?
Planowanie sprintu jest w Scrum wydarzeniem, które rozpoczyna sprint. Celem planowania sprintu jest określenie, co i w jaki sposób można zrealizować w nadchodzącym sprincie. Planowanie sprintu odbywa się we współpracy z całym zespołem Scrum.
W Scrumie sprint jest ustalonym okresem, w którym realizuje się całą pracę. Jednak zanim będzie można przejść do działania, trzeba zorganizować sprint. Musisz ustalić jego ramy czasowe, cel i punkt początkowy. Sesja planowania rozpoczyna sprint, wyznaczając plan jego przebiegu i obszar zainteresowania. Przeprowadzona poprawnie tworzy również środowisko, w którym zespół jest zmotywowany, gotowy na podjęcie wyzwań i ma szansę odnieść sukces. Złe plany sprintów mogą sprowadzić zespół na błędną ścieżkę w wyniku wyznaczenia nierealnych oczekiwań.
- Co — product owner opisuje cel ogólny (lub szczegółowy) sprintu oraz elementy backlogu przyczyniające się do realizacji tego celu. Zespół Scrum decyduje, co da się zrealizować w nadchodzącym sprincie i jakie działania zostaną podjęte w trakcie sprintu, aby osiągnąć cel.
- Jak — zespół tworzący oprogramowanie planuje pracę niezbędną do osiągnięcia celu sprintu. Ostatecznie, wynikowy plan sprintu jest efektem negocjacji między zespołem tworzącym oprogramowanie a product ownerem oraz opiera się na wartości i wysiłku.
- Kto — nie można zaplanować sprintu bez product ownera lub zespołu tworzącego oprogramowanie. Product owner definiuje cel w oparciu o wartość, do osiągnięcia której dąży. Zespół tworzący oprogramowanie musi ustalić, w jaki sposób może lub dlaczego nie może osiągnąć tego celu. Jeśli któraś ze stron nie będzie brała udziału w tym wydarzeniu, zaplanowanie sprintu będzie niemal niemożliwe.
- Dane wejściowe — doskonałym punktem wyjścia dla planu sprintu jest backlog produktu, ponieważ zawiera on listę „rzeczy”, które potencjalnie mogą stać się częścią bieżącego sprintu. Zespół powinien również przyjrzeć się dotychczasowej pracy z perspektywy przyrostu i mieć na uwadze potencjał wykonawczy.
- Rezultaty — najważniejszym wynikiem spotkania dotyczącego planowania sprintu jest możliwość opisania przez zespół celu sprintu oraz sposobu, w jaki zamierza go osiągnąć. Uwidacznia się to w backlogu sprintu.
Przygotowanie do spotkania dotyczącego planowania sprintu
Przeprowadzenie szeroko zakrojonego planowania sprintu wymaga pewnej dozy dyscypliny. Product owner musi być przygotowany i połączyć wnioski z przeglądu poprzedniego sprintu, informacje zwrotne od interesariuszy oraz wizję produktu, aby wyznaczyć podstawy dla sprintu. Na potrzeby zapewnienia przejrzystości backlog produktu powinien być aktualny i uporządkowany. Porządkowanie backlogu jest w Scrum wydarzeniem opcjonalnym, ponieważ niektóre backlogi go nie wymagają. Jednak w przypadku większości zespołów lepiej zebrać ich członków, aby przejrzeć i dopracować backlog przed przystąpieniem do planowania sprintu.
Jeśli planujesz dwutygodniowy sprint, zorganizuj w jego trakcie spotkanie w celu dopracowania backlogu. To dla zespołu doskonała okazja, aby wyjść poza sprint i zastanowić się, co dalej. Nie tylko ułatwia to przygotowanie do planowania, ale także pozwala spojrzeć na bieżącą pracę z innej perspektywy.
Ustalanie limitu czasu planowania sprintu
Planowanie sprintu powinno być ograniczone do maksymalnie dwóch godzin na każdy tydzień sprintu. W związku z tym, na przykład spotkanie dotyczące planowania dwutygodniowego sprintu nie powinno trwać dłużej niż cztery godziny. Nazywa się to ustalaniem ram czasowych lub wyznaczaniem maksymalnej ilości czasu, którą zespół ma na wykonanie zadania, którym w tym przypadku jest planowanie sprintu. Scrum Master odpowiada za poinformowanie o ramach czasowych, gdy spotkanie dochodzi do skutku. Jeśli zespół osiągnie zadowalający rezultat przed upływem limitu czasu, wydarzenie zostaje zakończone. Ramy czasowe wyznaczają maksymalny dopuszczalny czas. Czasu minimalnego się nie określa.
Koncentracja na wynikach, a nie na pracy
Podczas planowania sprintu łatwo „ugrzęznąć” w pracy, koncentrując się na tym, które zadanie powinno zostać wykonane jako pierwsze, kto powinien to zrobić i jak długo potrwa jego realizacja. W przypadku złożonej pracy poziom informacji, którym dysponujesz na początku, może być niski, a wiele danych opiera się na założeniach. Scrum jest procesem empirycznym, co oznacza, że nie da się planować z wyprzedzeniem. Trzeba uczyć się poprzez działanie, a następnie wprowadzać uzyskane informacje z powrotem do procesu.
Cel sprintu określa ogólne założenia, jednak elementy backlogu można tworzyć również z perspektywy rezultatów. Historyjki użytkowników są świetnym sposobem na opisanie pracy z punktu widzenia klienta. Historyjki użytkowników sformułowane w przedstawiony poniżej sposób pozwalają przekierować uwagę na wady, problemy i ulepszenia wyniku, które interesują klienta, a nie na sam obserwowany problem.
Dodanie wyraźnych, mierzalnych wyników do historyjki użytkownika pozwala w przejrzysty sposób zmierzyć wyniki, dzięki czemu wiesz, kiedy cel został zrealizowany. Doprecyzowując z wyprzedzeniem i w najwyższym możliwym stopniu prace, którymi zespół będzie się zajmował, zapewniasz wszystkim przejrzystość potrzebną do przystąpienia do pracy. Przykładowo pozostawienie niejasności jest znacznie gorsze niż opisanie czegoś w formie pytania, na które trzeba udzielić odpowiedzi w trakcie sprintu.
Niewiedza to nie to samo, co niejasność. Nie ignoruj niewiadomych, są elementem rzeczywistości towarzyszącej wykonywaniu trudnej pracy. Ale nie ukrywaj ich pod płaszczem niejasnych stwierdzeń. Zamiast tego jasno komunikuj, gdy czegoś nie wiesz, i uwzględnij w pracy konieczność uzyskania odpowiednich informacji.
Szacunki są niezbędne, ale nie udawaj, że wiesz więcej niż w rzeczywistości
Planowanie sprintu wymaga pewnej dozy szacowania. Zespół musi określić, co można, a czego nie można zrealizować w trakcie sprintu, czyli oszacować proporcje nakładu pracy do dostępnego potencjału wykonawczego. Szacowanie często bywa mylone ze zobowiązaniami. Szacunki z natury są prognozami opartymi na dostępnej wiedzy. Różne techniki, takie jak punkty historyjki czy rozmiary t-shirtów, zwiększają wartość procesu, pozwalając zespołowi spojrzeć na problem z innej perspektywy. Nie są to jednak magiczne narzędzia, które pozwoliłyby doszukać się prawdy tam, gdzie nie da się jej odnaleźć. Im więcej niewiadomych, tym mniej prawdopodobne jest trafne oszacowanie.
Dobre oszacowanie wymaga opartego na zaufaniu środowiska, w którym dąży się do nauki i doskonalenia poprzez swobodny przepływ informacji i omawianie założeń. Jeśli dane szacunkowe zostaną wykorzystane w niekorzystny, konfrontacyjny sposób po zakończeniu pracy, to prawdopodobne jest, że przyszłe szacunki będą albo zawyżone, aby wyeliminować możliwość pomyłki, albo czas potrzebny na ich opracowanie będzie znacznie dłuższy, ponieważ zespół będzie kwestionował własne wyniki z obawy o konsekwencje złego oszacowania.
Wypróbuj różne techniki szacowania, takie jak rozmiary t-shirtów lub punkty historyjki. Różne techniki pozwalają spojrzeć na problem z różnych perspektyw.
Najlepsze praktyki planowania sprintów
Łatwo ugrzęznąć w szczegółach planowania, zapominając, że jego istotą jest opracowanie „wystarczającego” planu dla kolejnego sprintu. Plan nie powinien być kulą u nogi zespołu, tylko ułatwić mu skoncentrowanie się na cennych wynikach i działać jak drogowskaz dla samodzielnej organizacji. Dobry plan sprintu motywuje każdego poprzez zdefiniowanie wyniku i wyraźne zaplanowanie sukcesu. Uważaj na planowanie ze zbyt dużym wyprzedzeniem. Zamiast tworzyć domknięty na ostatni guzik plan, w którym „każda minuta sprintu jest zagospodarowana”, skoncentruj się na celu i utwórz backlog sprintu wystarczający, aby rozpocząć prace. Następnie uporządkuj backlog produktu, aby dać zespołowi możliwość podjęcia pracy, jeśli cel sprintu uda się zrealizować wcześniej.
Scrum to ramy postępowania procesu mające na celu rozwiązywanie złożonych problemów. Jako że wymagają one podejścia empirycznego (uczenia się poprzez działanie), procesy empiryczne bardzo trudno zaplanować, dlatego nie warto się oszukiwać — nie można opracować idealnego planu. Zamiast tego skup się na wynikach i działaj. To nie musi być trudne, nawet jeśli problem, który starasz się rozwiązać, taki jest.
Chcesz zacząć? Dowiedz się, jak korzystać ze sprintów w Jira Software.
