Zaplanuj idealny sprint za pomocą szablonu Scrum Jira
Podziel duże projekty na wykonalne zadania i kamienie milowe w sprintach.
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, dyrektor ds. produktu Jira, 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ń.
What is the purpose of sprint planning?
The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen.
How to run a sprint planning meeting?
- 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.
Who are the key participants?
Sprint planning meetings can't be done without the product owner or the development team. The product owner defines the goal based on the value that they seek. The development team needs to understand how they can or can't deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.
What are the inputs?
A great starting point for the sprint plan is the product backlog as it provides a list of ‘stuff’ that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity.
What are the outputs?
The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal. This is made visible in the sprint backlog.
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 poprzedniego przeglądu sprintu, informacje zwrotne od interesariuszy oraz wizję produktu, aby wyznaczyć podstawy 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 tego nie wymagają. Jednak w przypadku większości zespołów lepiej jest zebrać 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
Focus on a 'just enough' plan
Ł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.
Prioritize goal-oriented planning
A good sprint plan motivates everyone by defining an outcome and a clear plan for success. Instead of building the most complete, “every minute of the sprint is accounted for” sprint plan, focus on the goal and build enough of a sprint backlog to get started.
Keep a flexible backlog
Ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.
Accept the empirical nature of scrum
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
