Nie bez powodu prognozy pogody podają 70-procentowe prawdopodobieństwo opadów, zamiast obiecywać, że deszcz spadnie dokładnie o 15:00. Wykorzystują one dostępne informacje, uwzględniają niepewność i aktualizują się w miarę napływania nowych danych. Nadal możesz zaplanować swoje popołudnie w oparciu o te prognozy, o ile nie pomylisz prognozy z gwarancją.
Planowanie sprintu działa na podobnej zasadzie. Zespół Scrumowy dysponuje rejestrem produktów, oszacowaniem dostępnego obciążenia oraz celem, który chce osiągnąć. Jednak niektóre szczegóły dotyczące pracy stają się jasne dopiero w trakcie trwania sprintu. Planowanie z godzinnym wyprzedzeniem pozostawia niewiele miejsca na takie odkrycia, natomiast rozpoczęcie pracy bez wspólnego kierunku utrudnia podjęcie decyzji, na co należy zwrócić uwagę.
Celem jest uzgodnienie wartościowego rezultatu oraz prognoza, ile pracy zespół jest w stanie wykonać, aby go osiągnąć. Na tej podstawie zespół może dostosowywać swój plan w miarę zdobywania nowych informacji, nie tracąc z oczu celu sprintu.
Niniejszy przewodnik obejmuje przygotowanie backlogu, harmonogram planowania z podziałem na etapy, praktyczne obliczenia obciążenia oraz przykład z obliczeniami, który pokazuje, jak dostosować plan w trakcie trwania sprintu.
TL;DR Planowanie sprintu pozwala zespołowi Scrumowi uzgodnić jeden cel sprintu, wybrać elementy backlogu i ustalić wstępny plan realizacji:
- Przygotuj się, dopracowując nadchodzące zadania oraz sprawdzając dostępność, niedokończone elementy, zależności oraz definicję gotowości.
- Oprzyj prognozę na rzeczywistym obciążeniu i dotychczasowych wynikach, uwzględniając urlopy, spotkania, obowiązki w zakresie wspierania oraz niepewność, nie zliczając jednak dwukrotnie podjętych zobowiązań
- Zakończ planowanie, tworząc wspólny backlog sprintu, a następnie dostosowuj plan realizacji w miarę jak zespół zdobywa nową wiedzę, jednocześnie dbając o realizację celu sprintu
- Wykorzystaj dwugodzinny przykładowy plan spotkania oraz przykład obliczeń obciążenia jako punkt wyjścia, dostosowując je do potrzeb zespołu.
Czym jest planowanie sprintu?
Planowanie sprintu to wydarzenie w ramach metodyki Scrum, odbywające się na początku każdego sprintu w celu uzgodnienia tego, co zespół chce osiągnąć i w jaki sposób podejdzie do zadania. Gromadzi ono cały zespół Scrum, w tym właściciela produktu, Scrum Mastera i programistów. Inni specjaliści, tacy jak inżynierowie ds. bezpieczeństwa lub osoby odpowiedzialne za kontakty z klientami, również mogą dołączyć, jeśli ich wkład pomoże zespołowi w podjęciu świadomych decyzji.
Zgodnie z Przewodnikiem Scrum każda sesja planowania powinna przynieść trzy wyniki: cel sprintu wyjaśniający wartość pracy, wybór elementów backlogu produktu wspierających ten cel oraz wstępny plan ich realizacji. Razem tworzą one backlog sprintu, który programiści na bieżąco aktualizują w miarę postępów sprintu.
Przewodnik Scrum przewiduje maksymalnie osiem godzin na sprint trwający jeden miesiąc, a krótsze sprinty zazwyczaj wymagają mniej czasu. Przy dobrze dopracowanym backlogu poniższy plan zmieści się w dwóch godzinach.
Jeśli niektóre z tych terminów są Ci obce, w naszym słowniczku znajdziesz podstawowe informacje na temat metodologii agile i Scrum.
Trzy pytania, na które odpowiada planowanie sprintu
Każda sesja planowania sprintu koncentruje się na trzech pytaniach:
- Dlaczego ten sprint jest wartościowy?
- Co możemy osiągnąć?
- A jak zrealizujemy te zadania?
Przewodnik Scrum organizuje planowanie wokół tych pytań, zaczynając od wartości, którą chcesz dostarczyć. Gdy wszyscy mają to jasno określone, łatwiej jest zdecydować, które elementy backlogu zasługują na uwagę i ile pracy zespół może realistycznie podjąć.
| Pytanie | Kto kieruje | Wynik | Przykład sprintu trwającego 2 tygodnie |
|---|---|---|---|
| Dlaczego ten sprint jest wartościowy? | Właściciel produktu przedstawia propozycję; cały zespół wyraża zgodę | Cel sprintu | Nowi klienci mogą zapłacić kartą przy kasie bez konieczności kontaktowania się z działem sprzedaży |
| Co można zrobić w tym sprincie? | Programiści dokonują wyboru wraz z właścicielem produktu | Wybrane elementy z rejestru zadań | Formularz płatności kartą, integracja z dostawcą usług płatniczych, e-mail z potwierdzeniem, obsługa błędów |
| W jaki sposób wybrane zadania zostaną zrealizowane? | Programiści | Wstępny plan zadań | Elementy są dzielone na zadania, z których każde zajmuje zazwyczaj jeden dzień lub mniej, a wstępny podział obowiązków jest uzgadniany |
Dlaczego sprint ma znaczenie
Cel sprintu wyznacza zespołowi kierunek działań i pomaga interesariuszom zrozumieć, czego mogą się spodziewać. Uzgodnij ten cel ze swoim zespołem Scrum przed zakończeniem sesji planowania.
Opisz wynik, który ludzie mogą rozpoznać, na przykład „Użytkownicy wersji próbnej mogą zapraszać członków zespołu”, zamiast celu związanego z obciążeniem pracą, takiego jak „Zrealizować 34 punkty fabularne”. Jeśli pojawi się nieoczekiwany problem, cel pomoże zespołowi zdecydować, które zadania należy dostosować, zachowując jednocześnie zamierzony wynik.
Czytaj więcej: Jak sformułować skuteczne cele sprintu (+przykłady)
Co zespół może zrealizować w tym sprincie
Po uzgodnieniu celu nadszedł czas, aby ustalić, co zespół jest w stanie realistycznie zrealizować.
Programiści wybierają elementy backlogu w porozumieniu z właścicielem produktu, biorąc pod uwagę dostępne obciążenie, dotychczasowe wyniki oraz definicję gotowości. Jest to również odpowiedni moment na przegląd wszelkich istniejących zobowiązań, które mogą wpłynąć na ilość czasu, jaką zespół ma do dyspozycji na pracę w ramach sprintu.
Wiele zespołów wykorzystuje punkty fabularne do porównywania względnego wysiłku i złożoności elementów backlogu. Skala Fibonacciego może pomóc w uporządkowaniu tych dyskusji, zwłaszcza gdy wysiłek nie jest jasno określony.
Jeśli nie masz doświadczenia z punktami fabularnymi lub chcesz zobaczyć, jak są one wykorzystywane w praktyce, oto przewodnik po procesie szacowania.
W jaki sposób zespół wykona zadania
Po wybraniu elementów backlogu programiści ustalają, w jaki sposób przekształcą je w gotowy przyrost produktu, który spełnia definicję „gotowości”. Przewodnik Scrum sugeruje podzielenie większych elementów na mniejsze zadania, często tak dobrane, aby ich wykonanie zajęło jeden dzień lub mniej.
Nie oznacza to jednak, że musisz szczegółowo zaplanować każdą godzinę sprintu. Pierwsze kilka dni może wymagać bardziej szczegółowego planu, podczas gdy późniejsze zadania mogą pozostać otwarte na dostosowania w miarę pojawiania się nowych szczegółów. Traktowanie wczesnych szacunków jako wiążących zobowiązań może wywierać presję na zespół, by dotrzymał pierwotnych założeń, nawet jeśli zakres prac ulegnie zmianie w trakcie realizacji.
Jak wyjaśnia Dave West, dyrektor generalny Scrum.org:
Prognoza wykorzystywana do uzasadnienia terminu sprzyja właśnie takim zachowaniom, które podważają zaufanie, jak zawyżanie szacunków, ukrywanie ryzyka czy ciche redefiniowanie pojęcia „zrobione”, aby osiągnąć wyznaczony wynik.
Prognoza wykorzystywana do uzasadnienia terminu sprzyja właśnie takim zachowaniom, które podważają zaufanie, jak zawyżanie szacunków, ukrywanie ryzyka czy po cichu zmieniające definicję „zrobione”, aby osiągnąć wyznaczony wynik.
Jaka jest różnica między planowaniem sprintu a udoskonalaniem backlogu?
Udoskonalenie backlogu pozwala zespołowi lepiej zrozumieć nadchodzące zadania, zanim nadejdzie czas na podjęcie decyzji o tym, co powinno znaleźć się w następnym sprincie. Planowanie sprintu opiera się na tych przygotowaniach i służy uzgodnieniu celu, wyborze elementów backlogu oraz ustaleniu wstępnego planu realizacji.
Te dwa działania służą różnym celom w ramach metodyki Scrum:
| Wymiar | Udoskonalanie backlogu | Planowanie sprintu |
|---|---|---|
| Cel | Wyjaśnij, podziel i oszacuj nadchodzące elementy z listy zadań | Ustal cel sprintu, wybierz zadania i planuj realizację |
| Harmonogram | Trwa przez cały czas trwania sprintu | Na początku każdego sprintu |
| Status Scrum | Czynność cykliczna | Formalne wydarzenie Scrumowe z określonym limitem czasowym |
| Kto bierze udział | Właściciel produktu i odpowiedni programiści | Cały zespół Scrum |
| Wynik | Elemente w backlogu z bardziej szczegółowymi informacjami, szacunkami i zakresem | Backlog sprintu: cel sprintu, wybrane elementy i plan realizacji |
Zadbaj o to, by wystarczająca liczba przyszłych elementów backlogu była dopracowana, tak aby zespół miał jasne możliwości wyboru podczas planowania sprintu. To, na ile przydatne są przygotowania, zależy od tego, jak szybko zmieniają się priorytety i jak duża jest niepewność. Elementy znajdujące się dalej w backlogu mogą pozostać mniej szczegółowe, dopóki nie zbliżą się do etapu wyboru.
Przeczytaj również: Aby uzyskać więcej wskazówek, zapoznaj się z naszymi artykułami na temat porządkowania backlogu oraz utrzymywania porządku i priorytetów w backlogu produktu.
Jak przygotować się do planowania sprintu
Kilka dni wcześniej sprawdź, czy lista zadań jest w dobrym stanie i czy wszyscy mają informacje potrzebne do podejmowania decyzji. Dzięki temu podczas sesji będziecie mogli poświęcić czas na omówienie tego, co ma zostać zrealizowane i jak do tego podejść, bez konieczności rozstrzygania każdego wymagania od podstaw.
Oto lista kontrolna, którą warto przejrzeć przed rozpoczęciem kolejnego sprintu:
- Sformułuj cel sprintu: Poproś właściciela produktu, aby zaproponował wynik wspierający szerszy cel produktu, dając zespołowi konkretne punkty do omówienia
- Przejrzyj rejestr produktów: Upewnij się, że elementy o najwyższym priorytecie są uporządkowane, zrozumiałe i oszacowane tam, gdzie to konieczne
- Sprawdź dostępność zespołu: poproś programistów o udostępnienie informacji o planowanych urlopach, dyżurach wsparcia technicznego i innych zobowiązaniach, które mogą wpłynąć na ich obciążenie
- Powrót do niedokończonych zadań: Przejrzyj zadania przeniesione z poprzedniego sprintu oraz wszelkie usprawnienia zidentyfikowane podczas retrospektywy
- Zidentyfikuj zależności: Oznacz zadania, które wymagają wkładu lub zatwierdzenia innego zespołu, i ustal, kto będzie koordynował te działania
- Przejrzyj definicję „zrobionego zadania”: Upewnij się, że wszyscy rozumieją standardy jakości, jakie musi spełniać każdy zakończony element z rejestru zadań
Jeśli planujesz retrospektywę sprintu i sesję planowania w krótkim odstępie czasu, zapewnij wystarczającą ilość czasu na rzetelną dyskusję podczas obu spotkań. Wyniki retrospektywy powinny wpłynąć na plan następnego sprintu, więc upewnij się, że żadne ze spotkań nie będzie przebiegało w pośpiechu.
Program planowania sprintu: przykładowy harmonogram dla sprintu trwającego 2 tygodnie
W przypadku dwutygodniowego sprintu zacznij od dwugodzinnej sesji planowania, zwłaszcza gdy lista zadań do wykonania została już dopracowana. Zaplanuj dodatkowy czas, jeśli zadania wiążą się ze złożonymi zależnościami lub wymagają podjęcia kilku decyzji, które należy omówić.
Ten próbny plan spotkania możesz dostosować do potrzeb swojego zespołu.
| Czas | Element porządku obrad | Kto kieruje | Oczekiwane wyniki |
|---|---|---|---|
| 0:00–0:10 | Przejrzyj wyniki poprzedniego sprintu, niedokończone zadania oraz działania wynikające z retrospektywy | Scrum Master pełni rolę moderatora | Wspólne zrozumienie tego, na co należy zwrócić uwagę |
| 0:10–0:30 | Omów proponowany przez właściciela produktu cel sprintu i uzgodnij pożądany wynik | Cały zespół Scrumowy | Projekt celu sprintu, który wszyscy rozumieją |
| 0:30–0:45 | Sprawdź dostępność członków zespołu i przeanalizuj ewentualne ograniczenia dotyczące obciążenia | Programiści | Realistyczny obraz dostępnego obciążenia |
| 0:45–1:15 | Wybierz elementy z rejestru zadań, które zapewniają wsparcie dla tego celu | Programiści wraz z właścicielem produktu | Wybór zadań, które zespół uważa za możliwe do zrealizowania |
| 1:15–1:45 | Podziel wybrane elementy na mniejsze części i omów sposób ich realizacji | Programiści | Wstępny plan realizacji zadań |
| 1:45–2:00 | Przejrzyj zależności, sprawdź poziom pewności i sfinalizuj cel sprintu | Cały zespół Scrumowy | Uzgodniony cel sprintu oraz lista zadań do wykonania w sprincie, gotowa do wykorzystania przez zespół |
Przed zakończeniem możesz przeprowadzić szybką ocenę pewności, np. metodą Fist of Five, w której każdy ocenia swoją pewność co do planu, pokazując od zera do pięciu palców. Jeśli ktoś przyzna niską ocenę, zapytaj, co budzi jego obawy. Może to ujawnić nierozwiązaną zależność, zbyt ambitną prognozę lub wymaganie, które wymaga dalszej dyskusji.
Celem jest zidentyfikowanie potencjalnych problemów, póki jest jeszcze czas na dostosowanie planu.
Jak przeprowadzić planowanie sprintu w 6 krokach
Po przygotowaniu listy zadań i potwierdzeniu listy uczestników rozpocznij sesję planowania. Celem jest tutaj pomoc zespołowi w przekształceniu priorytetów i dostępnego obciążenia w plan, co do którego zespół ma pewność, że uda mu się go zrealizować.
Krok 1: Przejrzyj poprzednie zadania i uzgodnij cel sprintu
Zacznij od krótkiego przeglądu tego, co zostało zakończone, co pozostało niedokończone oraz czy jakieś działania wynikające z retrospektywy powinny wpłynąć na następny sprint. Skoncentruj się na wszystkim, co mogłoby zmienić priorytety lub podejście zespołu, zamiast ponownie omawiać całe podsumowanie sprintu.
Następnie poproś właściciela produktu, aby przedstawił proponowany cel sprintu i wyjaśnił, w jaki sposób wspiera on szerszy cel produktu. Daj programistom możliwość zadawania pytań dotyczących zakresu, wskazywania zależności oraz sugerowania zmian.
Na przykład, jeśli celem jest umożliwienie klientom sfinalizowania transakcji bez konieczności kontaktowania się z działem sprzedaży, uzgodnijcie, jak ma wyglądać transakcja o powodzeniu. Czy obejmuje ona potwierdzenie płatności i obsługę błędów? Czy automatyczne dostarczanie potwierdzeń jest niezbędne w pierwszej wersji produktu?
Dyskusje te pomagają zdefiniować wynik, do którego zespół może dążyć. Sformułowanie może ulegać zmianom w miarę wybierania elementów backlogu, ale przed zakończeniem planowania wszyscy powinni uzgodnić ostateczny cel.
Krok 2: Oblicz dostępne obciążenie zespołu
Przed wyborem zadań ustal, ile czasu Twoi programiści mogą realistycznie poświęcić na sprint.
Zacznij od liczby dni roboczych i przewidywanej dostępności każdej osoby. Następnie uwzględnij zaplanowane urlopy, wydarzenia Scrumowe, obowiązki związane ze wsparciem oraz inne znane zobowiązania. Jeśli programista spędza połowę tygodnia na rozwiązywaniu problemów związanych z produkcją, godziny te są już zajęte i niedostępne dla zaplanowanych zadań sprintu.
Prosta kalkulacja wygląda następująco: Dostępne obciążenie = Łączna liczba godzin pracy − Znane zobowiązania
Na przykład programista, który w ciągu dwóch tygodni ma do dyspozycji 80 godzin roboczych, może mieć 8 godzin urlopu, 10 godzin spotkań i 12 godzin dyżurów w zakresie wsparcia. Pozostaje więc 50 godzin, nie uwzględniając żadnych dodatkowych czynników niepewności.
Porównaj tę wartość z dotychczasowymi wynikami zespołu. Prędkość (velocity) pokazuje, ile pracy zespół zakończył w poprzednich sprintach, natomiast obciążenie odzwierciedla czas dostępny na ten sprint.
Wskazówka dla profesjonalistów: Jeśli do planowania obciążenia wykorzystujesz godziny, oddziel je od punktów fabularnych. Są to dwie różne miary i nie ma między nimi uniwersalnego przelicznika.
Krok 3: Ponowna ocena zadań niedokończonych z poprzedniego sprintu
Niedokończone elementy z listy zadań zasługują na ponowne przeanalizowanie przed dodaniem ich do nowego sprintu. Element, który był ważny dwa tygodnie temu, mógł zmienić swój priorytet, albo zespół mógł zdobyć wiedzę, która wpływa na to, ile pracy pozostało do wykonania.
Przejrzyj każdy element wraz z właścicielem produktu i rozważ:
- Znaczenie: Czy nadal wspiera to proponowany cel sprintu lub inny ważny priorytet produktowy?
- Pozostały wysiłek: Ile pracy pozostało do wykonania po zakończeniu części elementu?
- Zależności: Czy coś uniemożliwia zespołowi osiągnięcie postępów?
- Priorytet: Czy ten element powinien mieć pierwszeństwo przed nowo dopracowanymi elementami z backlogu?
W przypadku zadań, które nadal należą do sprintu, wykorzystaj pozostały wysiłek, aby oszacować, ile zdolności produkcyjnej będą one wymagały. Połowa wykonanego elementu może wymagać mniej wysiłku niż pierwotnie szacowano, ale nadal liczy się jako niedokończony, dopóki nie spełni definicji gotowości.
Krok 4: Wybierz elementy z rejestru zadań, które zapewniają wsparcie dla tego celu
Dzięki zrozumieniu obciążenia i zaległych zadań programiści mogą wybrać elementy backlogu produktu, które według nich będą w stanie zrealizować.
Zacznij od elementów, które bezpośrednio wspierają cel sprintu. Omów ich kryteria akceptacji, zależności techniczne oraz wszelkie niepewności, które mogą wpłynąć na realizację. Jeśli dany element jest zbyt rozbudowany lub niejasny, rozważ podzielenie go na mniejsze części, które mogą przynieść wartość w ramach sprintu.
Możesz również uwzględnić prace konserwacyjne lub inne priorytety związane z produktem, ale sprawdź, czy podjęcie się tych zadań nie zagrozi realizacji głównego celu.
Ile obciążenia należy zarezerwować?
Zaplanowanie jedynie 80% dostępnego obciążenia może być rozsądnym punktem wyjścia dla zespołów, które regularnie zajmują się nieprzewidzianymi zadaniami wsparcia, jednak Scrum nie określa stałej wartości procentowej.
Jeśli Twój zespół doświadczał częstych zakłóceń, możesz zarezerwować 10–20% jego skorygowanego obciążenia i porównać ten zapas z tym, co było potrzebne podczas poprzednich sprintów. Zespół o stabilnym obciążeniu pracą i niewielką liczbą zakłóceń może potrzebować mniej. Zespół obsługujący działającą usługę, w której często zdarzają się awarie, może potrzebować więcej.
Unikaj podwójnego uwzględniania tego samego zobowiązania. Jeśli zaplanowane godziny wsparcia zostały już odjęte w kroku 2, dodatkowy bufor powinien pokrywać niepewność wykraczającą poza znane obciążenie pracą. Wynikową zdolność operacyjną potraktuj jako punkt odniesienia do dyskusji, a nie jako cel do osiągnięcia.
Pamiętaj: Sprint z wolnymi zasobami niekoniecznie oznacza niedoplanowanie. Jeśli wybrałeś wystarczającą ilość zadań, aby osiągnąć cel sprintu, wypełnienie pozostałych godzin zadaniami niezwiązanymi z celem może spowodować konflikt priorytetów. Czasami bardziej realistyczna jest skromniejsza prognoza, zwłaszcza gdy wybrane zadania wiążą się ze znaczną niepewnością.
Krok 5: Podziel zadania na mniejsze części i sprawdź zależności
Po wybraniu elementów backlogu programiści mogą opracować sposób ich realizacji. Może to obejmować podział większych elementów na zadania związane z programowaniem, testowaniem, integracją i weryfikacją.
Przyjrzyj się dokładnie kolejności zadań. Jeśli interfejs kasy zależy od zależności z dostawcą usług płatniczych, zespół powinien wiedzieć, kiedy ta zależność musi być gotowa. Jeśli inny zespół musi zatwierdzić zmianę dotyczącą bezpieczeństwa, wyjaśnij, w jaki sposób i kiedy ta decyzja zostanie podjęta.
Zaplanuj najbliższe zadania bardziej szczegółowo, pozostawiając późniejsze zadania otwarte do dalszej dyskusji. Przewodnik Scrum sugeruje podział wybranych elementów na mniejsze zadania, zazwyczaj trwające jeden dzień lub krócej, ale to programiści decydują, jak zorganizować i przeprowadzić dystrybucję pracy.
Sprawdź, czy plan uwzględnia definicję zakończenia (Definition of Done), w tym niezbędne testy i prace integracyjne. Jeśli jakaś zależność mogłaby uniemożliwić realizację, przed sfinalizowaniem planu ponownie przeanalizuj wybrane elementy lub dostosuj podejście do realizacji.
Krok 6: Sfinalizuj i udostępnij backlog sprintu
Zapisz cel sprintu, wybrane elementy backlogu produktu oraz wstępny plan realizacji w miejscu, do którego zespół ma dostęp i które może aktualizować. Wszystkie te elementy powinny jasno określać, co zespół zamierza osiągnąć i na jakich zadaniach należy się teraz skupić.
Przed zakończeniem spotkania upewnij się, że wszyscy zgadzają się co do celu, i daj każdemu szansę na zgłoszenie wszelkich pozostałych wątpliwości dotyczących prognoz. Jeśli ważna zależność lub problem związany z obciążeniem pozostaje nierozwiązany, omów, co należy zmienić, zanim zespół rozpocznie pracę.
W trakcie sprintu codzienne spotkanie (Daily Scrum) daje programistom możliwość sprawdzenia postępów w realizacji celu oraz dostosowania listy zadań do sprintu (sprint backlog). Wykres burndown lub burnup może pomóc w przedstawieniu zmian w postępach, a szczegółowe informacje dostarczają poszczególne zadania. Jeśli nowe informacje mają wpływ na wybrany zakres prac, programiści mogą omówić niezbędne dostosowania z właścicielem produktu (Product Owner) bez narażania celu sprintu na ryzyko.
Przykład planowania sprintu: zespół składający się z 6 programistów
Zobaczmy, jak te decyzje sprawdzają się w praktyce.
Wyobraź sobie, że planujesz dwutygodniowy sprint dotyczący produktu do rozliczeń B2B. Twój zespół składa się z sześciu programistów, a proponowany cel sprintu brzmi: „Nowi klienci mogą płacić kartą przy finalizacji zamówienia bez konieczności kontaktowania się z działem sprzedaży”.
Przed wyborem elementów backlogu musisz wiedzieć, ile czasu ma do dyspozycji zespół. W tym przykładzie załóżmy, że każdy programista ma sześć potencjalnych godzin na skupioną pracę nad projektem dziennie, przed odliczeniem zaplanowanych wydarzeń Scrumowych i innych zobowiązań.
Oto jak wygląda obliczanie obciążenia produkcyjnego w okresie 10 dni roboczych:
| Obliczanie obciążenia produkcyjnego | Godziny |
|---|---|
| Obciążenie bazowe: 6 programistów × 10 dni × 6 godziny | 360 |
| Zaplanowany urlop: 1 programista nieobecny przez 2 dni | −12 |
| Dyżur: 1 programista z dostępnością na poziomie 50% | −30 |
| Wydarzenia Scrumowe: 8 godzin na programistę | −48 |
| Dostępne obciążenie | 270 |
| Zarezerwuj 20% czasu na zadania nieprzewidziane | −54 |
| Dostępne obciążenie na zaplanowane zadania | 216 |
Po uwzględnieniu przykładowego 20-procentowego bufora masz teraz 216 godzin na zaplanowaną pracę. W praktyce wielkość tego bufora należy dobrać na podstawie tego, w jakim stopniu nieplanowane zadania zakłócały przebieg poprzednich sprintów.
Wybierz zadania, które wspierają cel sprintu
Po ustaleniu obciążenia programiści wraz z właścicielem produktu przeglądają elementy backlogu związane z realizacją.
Oto przykładowy wybór oparty na wstępnych szacunkach nakładu pracy na poziomie poszczególnych zadań:
| Element z rejestru zadań | Szacowany wysiłek |
|---|---|
| Stwórz formularz płatności kartą | 48 godzin |
| Zintegruj dostawcę usług płatniczych | 88 godzin |
| Postępuj w przypadku nieudanych płatności i błędów walidacji | 50 godzin |
| Dodaj potwierdzenie płatności i dostarczenie pokwitowania | 24 godziny |
| Całkowita ilość pracy planowanej | 210 godzin |
Szacunki te pozostawiają 6 godzin w ramach limitu pracy planowanej oraz 54-godzinny bufor na nieprzewidziane zadania. Zespół ma również w rejestrze produktów zadanie dotyczące ulepszenia pulpitu dla raportowania. Chociaż jest to wartościowe zadanie, nie przyczynia się ono bezpośrednio do osiągnięcia celu sprintu. Właściciel produktu i programiści uzgadniają, że pozostawią je na przyszły sprint.
Dostosuj plan, gdy coś się zmieni
Szóstego dnia dostawca usług płatniczych wprowadza zmianę w interfejsie API, która powoduje awarię części integracji. Programiści badają sytuację i szacują zakres dodatkowych prac, które należy wykonać.
Zamiast kontynuować realizację pierwotnej kolejności zadań, omawiają wpływ tej zmiany z właścicielem produktu. Jeśli poprawka mieści się w ramach pozostałego obciążenia produkcyjnego, mogą nadać jej priorytet i odłożyć opcjonalne dostosowanie stylu potwierdzeń lub inne zadanie o niższym priorytecie. Potwierdzenie płatności i inne niezbędne prace nadal muszą spełniać kryteria definicji zakończenia.
Jeśli zakres poprawek okaże się większy niż oczekiwano, konieczne będzie ponowne oszacowanie pozostałego zakresu prac oraz ustalenie, czy cel sprintu jest nadal możliwy do osiągnięcia.
Zespół może zakończyć sprint z mniejszą liczbą zakończonych elementów backlogu niż pierwotnie przewidywano. Jeśli jednak klienci mogą dokonać płatności zgodnie z zamierzeniami, a praca spełnia definicję „gotowości”, oznacza to, że cel sprintu został osiągnięty.
Przykłady celów sprintu dla innych zespołów
To samo podejście do planowania można zastosować do zadań wykraczających poza tworzenie oprogramowania, chociaż sam Scrum jest konkretną metodologią o zdefiniowanych obowiązkach i wydarzeniach.
Na przykład zespół marketingowy może wyznaczyć sobie cel taki jak: „Opublikować stronę docelową webinarium i umożliwić odwiedzającym rejestrację bez pomocy operatora”. Zespół operacyjny może natomiast postawić sobie za cel: „Zapewnić, aby każdy pracownik z kolejnej grupy nowo zatrudnionych miał w pierwszym dniu pracy niezbędny sprzęt i dostęp do systemu”.
Oba cele opisują wyniki, które mogą kierować decyzjami zespołu w trakcie całego sprintu. Elementy z backlogu i plany realizacji będą się różnić, ale zespół nadal musi wziąć pod uwagę swoje obciążenie i uzgodnić, jak ma wyglądać powodzenie realizacji.
Typowe błędy podczas planowania sprintu i sposoby ich naprawiania
Planowanie sprintu może napotkać problemy, gdy zespoły wykorzystują punkty fabularne do oceny indywidualnych wyników, wprowadzają na spotkanie niejasne elementy z rejestru zadań, przydzielają zadania w zbyt sztywny sposób lub pomijają wymagania testowe i zależności zewnętrzne.
Kilka drobnych zmian może pomóc Ci wychwycić te problemy, zanim wpłyną one na realizację projektu.
| Błąd | Dlaczego powoduje to problemy | Jak to naprawić |
| Wykorzystanie punktów fabularnych do pomiaru indywidualnej wydajności | Porównywanie programistów na podstawie liczby zakończonych punktów może zachęcać do zawyżania szacunków lub unikania złożonych zadań. | Skup się na punktach fabularnych w kontekście prognozowania na poziomie zespołu. Przejrzyj zakończone zadania z kilku sprintów i omów zmiany w szacunkach podczas fazy dopracowywania. Oceniaj indywidualne wyniki na podstawie jakości kodu, współpracy i osiągniętych rezultatów. |
| Włączanie niejasnych elementów z listy zadań do planowania | Brak kryteriów akceptacji lub nierozstrzygnięte kwestie techniczne sprawiają, że planowanie zamienia się w dyskusję na temat tego, co należy stworzyć, pozostawiając mniej czasu na zaplanowanie realizacji. | Rozwiąż wątpliwości podczas dopracowywania backlogu, aby programiści mogli sporządzić realistyczną prognozę. Jeśli nadal występuje niepewność, rozważ mniejszy, lepiej zrozumiały element pracy. Staraj się osiągnąć wystarczającą jasność, aby podjąć decyzję, zamiast dążyć do idealnych specyfikacji. |
| Przydzielenie każdego zadania konkretnej osobie przed rozpoczęciem pracy | Stałe przydziały zadań utrudniają dostosowanie się w sytuacji, gdy zmieniają się priorytety lub gdy jeden programista kończy pracę przed terminem, a inny potrzebuje pomocy. | Pozwól programistom zorganizować pracę. Uzgodnijcie bezpośrednie obowiązki i wkład specjalistów, a następnie pozwól członkom zespołu przejmować zadania, pracować nad nimi w parach lub redystrybuować je w trakcie sprintu. Zadbaj o to, by praca była widoczna dla całego zespołu. |
| Pozostawianie nierozwiązanych zależności zewnętrznych | Brakujące dane uwierzytelniające do API, przeglądy bezpieczeństwa lub wyniki pracy innego zespołu mogą sprawić, że zespół będzie musiał czekać na zadania, nad którymi nie ma kontroli. | Przed sfinalizowaniem backlogu sprintu określ niezbędne dane wejściowe, kto będzie je koordynował oraz kiedy mają zostać dostarczone. Jeśli kluczowa zależność pozostaje niepewna, rozważ alternatywny element lub mniejszy zakres prac, który zespół może zrealizować samodzielnie. |
Jeśli te same problemy pojawiają się w wielu sprintach, porusz je podczas retrospektywy sprintu i uzgodnijcie zmianę, którą będziecie mogli przetestować podczas następnego sprintu. Te szablony retrospektyw sprintu pomogą Ci zapisać spostrzeżenia i działania następcze.
Pod koniec sprintu wykorzystaj spotkanie przeglądowe sprintu, aby wspólnie z interesariuszami sprawdzić zakończony przyrost i omówić, czym zespół powinien zająć się w następnej kolejności.
Jak przeprowadzić planowanie sprintu w ClickUp
Planowanie sprintu wymaga więcej wysiłku, gdy zadania, szacunki obciążenia i decyzje dotyczące planowania są rozproszone w różnych narzędziach. ClickUp gromadzi te informacje w jednym miejscu, dzięki czemu zespół może przeglądać zadania w kontekście obciążenia oraz weryfikować decyzje dotyczące planowania w razie zmian w planie.
Zacznij od szablonu planowania sprintu w metodologii Agile w ClickUp. Widoki zaległości, statusu rozwoju i zasobów pomogą Ci przejrzeć nadchodzące zadania i przygotować się do dyskusji planistycznej.
Oto jak podjąć kluczowe decyzje:
- Ułatw ocenę nadchodzących zadań: Przechowuj wymagania, kryteria akceptacji, priorytety i zależności na liście zadań ClickUp. Te szczegóły pomagają programistom omówić zakres i oszacować wysiłek przed wyborem zadań. Dodaj wybrane zadania do sprintu, gdy zespół uzgodni już plan.
- Ustal stały przedział czasowy na planowanie: Skonfiguruj czas trwania sprintu i daty rozpoczęcia w ClickUp Sprints. Wykorzystaj punkty sprintowe lub szacowany czas, aby oszacować wysiłek i pomóc zespołowi ocenić, ile zadań jest w stanie podjąć.
- Sprawdź, czy zadania są odpowiednio dopasowane: Porównaj przydzielone zadania z obciążeniem każdej osoby w widoku obciążenia pracą w ClickUp. Przejrzyj nierównomierny rozkład obciążenia pracą i omów ewentualne zmiany przed sfinalizowaniem prognozy.
- Dbaj o to, by plan spotkania i decyzje były ściśle powiązane z pracą: Skorzystaj z ClickUp Docs, aby sporządzić harmonogram, zaproponować cel sprintu oraz zamieścić linki do odpowiednich zadań. Zapisuj decyzje dotyczące zakresu oraz nierozstrzygnięte kwestie podczas sesji, aby zespół mógł do nich powrócić w miarę postępu prac.
- Rejestruj dyskusję podczas planowania: ClickUp AI Notetaker może rejestrować spotkania w Zoom, Google Meet, Microsoft Teams lub SyncUps i zapisywać podsumowanie, kluczowe decyzje oraz zadania do wykonania w dokumencie. Przejrzyj notatki, a następnie zaktualizuj zadania sprintu o uzgodnione działania następcze.
- Wykorzystaj dane dotyczące postępów do ukierunkowania dyskusji: Dodaj karty „Sprint Burndown” lub „Burnup” do pulpitów nawigacyjnych ClickUp, aby przejrzeć zakończoną pracę i pozostały wysiłek. Gdy postępy odbiegają od planu, przejrzyj odpowiednie zadania pod kątem opóźnień lub zmian zakresu, które wymagają uwagi.
Przed kolejną sesją planowania zapytaj Brain²: „Jakie nierozwiązane zależności pojawiły się podczas naszej ostatniej sesji planowania sprintu?”. Brain może pobrać kontekst z zapisanych notatek ze spotkania. Porównaj te szczegóły z bieżącymi zadaniami, zanim wykorzystasz je do sporządzenia kolejnej prognozy.
Ceny ClickUp
Najlepsze rozwiązanie dla: zespołów Scrumowych zarządzających wieloma sprintami, wspólnymi zależnościami i zmiennym obciążeniem pracą, które potrzebują zarządzania zaległościami, planowania wydajności i raportowania postępów w jednym obszarze roboczym. Rozwiązanie to sprawdza się również w przypadku zespołów koordynujących prace w ramach sprintów z szerszymi projektami produktowymi lub biznesowymi.
Pomiń to, jeśli: Twój zespół potrzebuje jedynie podstawowej tablicy Scrum z niewielkim backlogiem i minimalną ilością raportów. Elastyczność ClickUp wiąże się z koniecznością podejmowania decyzji dotyczących ustawień sprintu, widoków i pól. Niektóre zaawansowane funkcje raportowania i automatyzacji sprintów wymagają również planów wyższych poziomów, co może być zbędne w przypadku prostego cyklu pracy.
Jak dużo należy zaplanować przed rozpoczęciem sprintu?
Sesja planowania sprintu powinna zapewnić zespołowi wystarczającą jasność, aby mógł rozpocząć pracę.
Powyższy harmonogram z podziałem na czas oraz przykład obciążenia stanowią punkt wyjścia. Dostosuj je do obciążenia pracą zespołu, a następnie porównaj prognozę z zakończoną pracą i przerwami, aby usprawnić następne spotkanie.
W ClickUp możesz połączyć notatki z planowania z zadaniami sprintu i aktualizować backlog sprintu w miarę zmian w zakresie prac. Zespół może odwołać się do uzgodnionego planu przy podejmowaniu decyzji o ewentualnych korektach.
Najczęściej zadawane pytania dotyczące planowania sprintu
Jaka jest różnica między planowaniem sprintu a planowaniem wydania?
Planowanie sprintu koncentruje się na tym, co zespół zamierza osiągnąć w trakcie jednego sprintu oraz w jaki sposób zrealizuje te zadania. Planowanie wydania uwzględnia dłuższą perspektywę, np. które funkcje mogą być dostępne w ciągu kilku sprintów i kiedy użytkownicy mogą je otrzymać. Prognozy dotyczące wydania mogą ulegać zmianom w miarę zdobywania przez zespoły nowych informacji, podczas gdy cel każdego sprintu wyznacza kierunek prac w ramach bieżącego sprintu.
Czy potrzebujesz definicji gotowości do planowania sprintu?
Nie. Scrum nie wymaga formalnej definicji gotowości. Niektóre zespoły stosują ją, aby przed wyborem elementów backlogu ustalić wspólne oczekiwania, takie jak jasne wymagania, wykonalny zakres i znane zależności. Kryteria te powinny być na tyle elastyczne, aby zapewnić wsparcie dla dyskusji, nie uniemożliwiając jednocześnie zespołowi dopracowywania elementów w razie potrzeby.
Czy sprint można odwołać po zakończeniu planowania?
Tak. Tylko właściciel produktu może odwołać sprint, a odwołanie jest możliwe, gdy cel sprintu staje się nieaktualny, na przykład z powodu znacznej zmiany priorytetów biznesowych lub warunków rynkowych. Samo trudne zadanie lub niedokładne oszacowanie niekoniecznie uzasadnia odwołanie.
Jaka jest różnica między sprintem a metodą agile?
Metodologia Agile to szerokie podejście do zarządzania pracą oparte na wartościach i zasadach Manifestu Agile. Sprint to ustalony okres trwający maksymalnie jeden miesiąc w ramach metodyki Scrum, podczas którego zespół dąży do osiągnięcia celu sprintu i tworzy użyteczny przyrost. Można stosować zasady Agile bez korzystania ze sprintów. Na przykład metoda Kanban wspiera ciągły przepływ pracy bez konieczności stosowania iteracji o stałej długości.
Czy jeden sprint może mieć wiele celów?
W metodologii Scrum jeden cel sprintu jest definiowany jako jedyny cel tego sprintu. Możesz wybierać elementy backlogu, które zapewniają wsparcie dla innych priorytetów, o ile nie zagrażają one realizacji tego celu. Jeśli Twój zespół regularnie potrzebuje kilku niepowiązanych ze sobą celów, przed rozpoczęciem planowania omów, czy te zadania zapewniają wsparcie dla szerszego, wspólnego rezultatu, czy też konieczne jest rozstrzygnięcie sprzecznych priorytetów.
Czy podczas planowania sprintu należy szacować błędy w punktach fabularnych?
W metodologii Scrum punkty fabularne są opcjonalne, również w przypadku błędów. Zespoły, które szacują nakład pracy związany z usunięciem błędów, powinny uzgodnić, kiedy i dlaczego to robią. Znane usterki można ocenić podczas planowania, natomiast błędy wykryte w trakcie rozwoju mogą wchodzić w zakres prac już niezbędnych do osiągnięcia definicji „zrobione”. Należy unikać podwójnego liczenia tego samego wysiłku.