Czy jesteś gotowy, aby jak najlepiej wykorzystać planowanie sprintu? Jako kierownik projektu zwinnego lub właściciel produktu, to od Ciebie zależy, czy wszyscy będą mieli wspólne spojrzenie na sytuację i czy uda się osiągnąć rezultaty.
Czas więc uporządkować chaos i precyzyjnie określić kryteria sukcesu dzięki temu kompleksowemu przewodnikowi, który sprawi, że planowanie sprintu będzie tak uporządkowane, że nawet Marie Kondo będzie musiała uznać Twoją wyższość! Chociaż dobre narzędzie do zwinnego zarządzania projektami może być bardzo pomocne, nic nie zastąpi ludzkich umysłów i pracy zespołowej przy tworzeniu udanego planu sprintu.
Dlatego w tym kompleksowym przewodniku omówię wszystko, czego potrzebujesz do zaplanowania udanych sprintów — w tym określenie celu sprintu, przygotowanie do spotkania dotyczącego planowania sprintu, opracowanie agendy spotkania oraz inne sprawdzone praktyki.
Czym jest planowanie sprintu?
Planowanie sprintu to początkowa faza cyklu tworzenia oprogramowania zgodnego z podejściem zwinnym i część zwinnego planowania projektu. Podczas tego spotkania cały zespół zbiera się na spotkaniu dotyczącym planowania sprintu, aby określić pracę do wykonania w ramach sprintu i stworzyć plan osiągnięcia tych celów.
Spotkanie dotyczące planowania sprintu zazwyczaj składa się z dwóch części:
- „Dlaczego” i „co” w sprincie: zespół ustala cel sprintu i uzgadnia, co zostanie wykonane. Wybiera elementy z rejestru produktu, które zostaną zrealizowane w ramach sprintu. Narzędzia do planowania projektów z funkcjami planowania sprintu mogą pomóc w organizowaniu i ustalaniu priorytetów elementów rejestru, dzięki czemu zespół pozostaje skoncentrowany na celach sprintu i działa zgodnie z nimi.
- „Jak” w sprincie: deweloperzy omawiają szczegóły poszczególnych elementów rejestru i dzielą je na zadania. Każde zadanie jest tak opracowane, aby można je było ukończyć w ciągu jednego dnia roboczego lub krócej, a jego realizację można śledzić za pomocą narzędzia do zarządzania zadaniami.
W zależności od długości sprintu spotkanie dotyczące planowania trwa od dwóch do ośmiu godzin. Jego czas powinien być ograniczony zgodnie z długością sprintu (np. maksymalnie 4 godziny w przypadku sprintu trwającego dwa tygodnie).
Pod koniec spotkania cel sprintu i zadania do wykonania powinny być ustalone, a sprint powinien zostać oficjalnie rozpoczęty.
Dlaczego planowanie sprintu jest ważne?
Planowanie sprintu jest ważne, ponieważ wyznacza jasny kierunek dla nadchodzącego sprintu zespołu. Dobrze przeprowadzona sesja planowania sprintu może:
- zapewnić jasne i wspólne zrozumienie celów oraz założeń projektu
- umożliwić zespołom ustalenie priorytetów i wybór elementów prac do wykonania w nadchodzącym sprincie
- promować skuteczne przydzielanie zasobów i zarządzanie czasem
- sprzyjać współpracy i komunikacji między członkami zespołu
Ogólnie rzecz biorąc, planowanie sprintu jest ważnym etapem przygotowawczym w zwinnym zarządzaniu projektami. Tworzy podstawę dobrze zorganizowanego i wydajnego sprintu, umożliwiając zespołom dostarczanie wysokiej jakości rezultatów w określonym limicie czasowym.
Kto uczestniczy w planowaniu sprintu?
Krótko mówiąc, cały zespół Scrum powinien uczestniczyć w planowaniu sprintu i brać udział w wydarzeniu Scrum na początku każdego sprintu. W skład tego zespołu mogą wchodzić:
- Właściciel produktu: dostarcza informacje na temat wizji produktu, doprecyzowuje wymagania i ustala priorytety elementów rejestru, które mają zostać uwzględnione w sprincie.
- Scrum Master (w niektórych zespołach nazywany trenerem zwinnym i nie należy go mylić z kierownikiem projektu): prowadzi spotkanie, dba o przestrzeganie uzgodnionego przepływu pracy i o to, aby uczestnicy wypracowali wspólne rozumienie celu sprintu.
- Deweloperzy: zapewniają wiedzę techniczną i przedstawiają opinie dotyczące wykonalności oraz nakładu pracy potrzebnego do wdrożenia historyjek użytkownika.
Czasami w charakterze konsultantów dołączają również interesariusze z firmy, jeśli mogą przedstawić ważną perspektywę lub przekazać przydatną wiedzę.
Jak przygotować się do spotkania dotyczącego planowania sprintu?
Przed skutecznym spotkaniem właściciel produktu (PO) powinien przygotować następujące rzeczy:
- Wnioski z ostatniego przeglądu sprintu i retrospektywy sprintu, a także informacje zwrotne od interesariuszy znajdujące się w backlogu.
- Przegląd już wykonanej pracy.
Ponadto właściciel produktu powinien przygotować się do spotkania dotyczącego planowania sprintu, przeprowadzając kilka procesów, które omówię bardziej szczegółowo poniżej. Obejmują one:
- Wstępne zdefiniowanie celu sprintu wraz z powiązanymi, ustalonymi priorytetami elementami backlogu, które można omówić podczas planowania.
- Regularne udoskonalanie backlogu, podczas którego aktualizowane są najważniejsze pozycje.
- Ocena szybkości i wydajności zespołu na potrzeby następnego sprintu.
Poniżej szczegółowo opiszę te trzy działania.
Czym jest cel sprintu?
Podczas planowania sprintu właściciel produktu i deweloperzy uzgadniają konkretny cel sprintu. Cel sprintu opisuje rezultat lub efekt nowego sprintu, nad którym pracuje zespół. Jest to krótkoterminowy kamień milowy na drodze do finalnego produktu.
Celem jest to, aby na koniec sprintu istniał przyrost produktu gotowy do dostarczenia, który już zapewnia korzyść klientom.
Czym jest backlog?
Jeśli jesteś właścicielem produktu, prawdopodobnie słyszałeś termin „backlog” więcej razy, niż jesteś w stanie zliczyć. Ale czym właściwie on jest? Oczywiście na podstawowym poziomie wszyscy wiemy, że jest to lista zadań lub funkcjonalności, które należy ukończyć.
Jednak gdy przechodzimy do szczegółów, takich jak różnica między backlogiem produktu a backlogiem sprintu, sprawy szybko się komplikują, więc zapnij pasy i zanurzmy się w temat!
Backlog produktu a backlog sprintu
Zespół Scrum gromadzi w backlogu produktu wszystkie historyjki użytkownika, epiki i zadania wymagane do stworzenia finalnego produktu. Właściciel produktu ustala priorytety elementów backlogu, tak aby historyjki o najwyższej wartości dla klientów znalazły się na górze. Ustalanie priorytetów zwykle odbywa się wspólnie z deweloperami.
Backlog produktu nie jest jednak ostateczną listą utworzoną na początku fazy tworzenia i następnie przetwarzaną. Nie — lista ta stale rośnie i zmienia się z czasem.
Rozwija się zarówno dzięki wiedzy zdobywanej podczas sprintów, jak i dzięki nowym wymaganiom pojawiającym się w przyszłości. Dlatego regularne udoskonalanie backlogu jest konieczne, aby uwzględniać te zmiany.
Załóżmy na przykład, że backlog produktu składa się ze wszystkich historyjek niezbędnych do stworzenia strony internetowej, np. strony głównej, formularza kontaktowego i stron produktów. Jeśli zespół marketingowy nagle zda sobie sprawę, że bezwzględnie potrzebuje na stronie sekcji blogowej, można ją dodać do backlogu i odpowiednio ustalić dla niej priorytet.
W przeciwieństwie do backlogu produktu backlog sprintu zawiera wyłącznie elementy backlogu wybrane do bieżącego sprintu oraz ogólny cel sprintu.
Jak szacować elementy backlogu?
Ile pracy zespół może wykonać w ramach sprintu? To jedno z kluczowych pytań, na które deweloperzy muszą odpowiedzieć podczas planowania sprintu. Aby móc dokonać prognozy, przeprowadzają oszacowanie.
Może to być dość trudne, ponieważ zespół ma do czynienia z wieloma nieznanymi zmiennymi. Jednak z czasem i wraz z doświadczeniem zdobywanym podczas ukończonych sprintów zespół coraz lepiej radzi sobie z szacowaniem.
Jak obliczyć szybkość i wydajność zespołu?
Przed rozpoczęciem szacowania należy znać średnią wydajność poprzednich sprintów (szybkość) oraz dostępną wydajność zespołu w nadchodzącym sprincie, która może być zmniejszona z powodu szkoleń, urlopów itp.
Na podstawie tych ustaleń zespół szacuje ilość pracy (szybkość), z którą może poradzić sobie w sprincie, następnie ocenia poszczególne elementy backlogu i wybiera, ile z nich uwzględnić w backlogu sprintu.
Załóżmy, że średnia szybkość w ciągu ostatnich kilku sprintów (cykl dwutygodniowy) wynosiła 40 punktów historyjek i nie przewiduje się znaczącego zmniejszenia dostępności członków zespołu. W takim przypadku zespół będzie planować, utrzymując tę samą szybkość (tj. wybrane elementy backlogu na potrzeby nadchodzącego sprintu będą obejmować około 40 punktów historyjek).
Chociaż średni czas realizacji zadania można zazwyczaj śledzić za pomocą dobrego narzędzia do śledzenia czasu, można również wykorzystać kilka innych metod szacowania do zwinnego planowania wydajności i określenia prędkości zespołu.
Metody szacowania: krótki przegląd
Czy chcesz lepiej zrozumieć sztukę szacowania? Przy różnych metodach i zmiennych może się ono często wydawać onieśmielającym tematem — ale nie martw się! Dzięki poznaniu podstaw szybko zdobędziesz umiejętności potrzebne do oszacowania swojego backlogu.
Punkty historyjek
Wiele zwinnych zespołów pracujących nad długoterminowymi projektami szacuje swoją prędkość w punktach historyjek.
Punkty historyjek to abstrakcyjna jednostka, której zespół używa do oszacowania nakładu pracy potrzebnego do ukończenia elementu backlogu. Opiera się to na trzech kryteriach:
- Zakres pracy: Ile podzadań trzeba ukończyć, aby zrealizować historyjkę użytkownika?
- Ryzyko i niepewność: Czy wszystkie wymagania są jasne, czy mogą wystąpić nieprzewidziane opóźnienia i zmiany?
- Złożoność historyjki: Czy poszczególne podzadania są ze sobą powiązane, przez co zwiększa się złożoność historyjki? Czy istnieją zależności poza zespołem?
Ciąg Fibonacciego i liczby pierwsze
Zwinne planowanie z wykorzystaniem ciągu Fibonacciego i liczb pierwszych pomaga zespołom tworzyć prognozy oparte nie tylko intuicyjnie na optymizmie, lecz także na zasadach logiki numerycznej.
Jeśli historyjka użytkownika ma wiele zmiennych i jest złożona lub obejmuje duży zakres, przypisanie jej wyższej liczby w skali Fibonacciego oznacza, że zespół jest przygotowany na przeznaczenie wystarczających zasobów i nakładu pracy na jej realizację — ponieważ zna już zakres pracy związany z takim przedsięwzięciem.
Z drugiej strony historyjkom z mniejszą liczbą zmiennych lub prostszymi rezultatami przypisuje się niższe liczby — co pozwala na dokładniejsze zaplanowanie czasu i energii. Krótko mówiąc, zwinne planowanie zabiera nadzieje i marzenia ze stołu w sali konferencyjnej, a zamiast nich kładzie na nim konkretne, namacalne liczby!
Należy jednak pamiętać, że punkty historyjek niekoniecznie są porównywalne między zespołami tworzącymi oprogramowanie, ponieważ każdy zespół nieco inaczej szacuje zakres. Oznacza to, że historyjka, którą zespół A ocenia na 5 PH, dla zespołu B może być historyjką na 8 PH.
Szacowanie za pomocą punktów historyjek sprawdza się również w przypadku mniejszych zespołów lub projektów, ponieważ tą metodą zespół ocenia zadania na podstawie ich złożoności i czasu potrzebnego na ich realizację. Inne techniki obejmują szacowanie nakładu pracy na podstawie rozmiarów koszulek lub metodę pokera planistycznego.
Rozmiary koszulek
Szacowanie elementów backlogu za pomocą rozmiarów koszulek to interesujące podejście do ustalania priorytetów zadań projektowych. Zamiast przypisywać zadaniu dokładną liczbę godzin lub dni, można przypisać mu jeden z czterech rozmiarów (mały, średni, duży i bardzo duży) w zależności od stopnia jego złożoności lub niepewności.
To uproszczony, a zarazem zaskakująco skuteczny sposób na zapewnienie, że właściwe zadania zostaną wykonane we właściwym czasie — niezależnie od tego, czy masz do czynienia z małym, średnim czy dużym projektem, wystarczy wybrać odpowiedni rozmiar. Upewnij się tylko, że wszyscy zaangażowani w projekt zgadzają się co do tego, jaki konkretny szacowany poziom nakładu pracy odpowiada każdemu rozmiarowi!
Poker planistyczny
Jeśli szukasz sprytnego sposobu na oszacowanie elementów backlogu, może warto wypróbować pokera planistycznego?
To popularna technika, która istnieje od 2002 roku, kiedy James Grenning ukuł ten termin.
Podejście jest proste: członkowie zespołu anonimowo przedstawiają swoje szacunki, wybierając karty z talii kart do pokera planistycznego, które przedstawiają różne wartości szacunkowe (tj. szacowaną liczbę punktów historyjki dla danego elementu).
Zachęca to wszystkich do wyrażenia swojej opinii bez obawy przed oceną lub wyśmianiem przez innych. Gdy wszyscy członkowie zespołu wprowadzą swoje szacunki i zostanie osiągnięty konsensus, zespół przechodzi do kolejnego elementu.
Agenda planowania sprintu
A więc wszystkie niezbędne przygotowania są już za Tobą i wreszcie nadszedł czas spotkania poświęconego planowaniu sprintu. Planowanie sprintu Scrum zwykle przebiega według następującej agendy:
- Właściciel produktu (PO) przedstawia wcześniej określony cel sprintu i dzieli się swoim pomysłem na zwiększenie wartości produktu w nadchodzącym sprincie. Ostateczny cel sprintu jest definiowany wspólnie przez właściciela produktu i deweloperów.
- PO wskazuje (ustalone według priorytetów) elementy rejestru produktu, które należy wdrożyć, aby osiągnąć cel.
- Zespół szacuje nakład pracy dla poszczególnych wpisów, jeśli nie zostało to już wcześniej zrobione (np. podczas udoskonalania rejestru). W razie potrzeby zespół doprecyzowuje poszczególne wpisy lub treści (np. kryteria akceptacji w formacie given-then-when).
- Zespół wybiera elementy rejestru produktu, które dostarczy do końca sprintu. Na tym etapie właściciel produktu omawia z deweloperami zadania, które należy wykonać, w oparciu o wartość dla klienta i nakład pracy. Czy wybrane elementy wystarczą, aby osiągnąć cel sprintu i stworzyć wartość dla klienta? Ostatecznie deweloperzy sami decydują, ile pracy podejmą się w sprincie. Ważne: Ten wybór nie jest zobowiązaniem wobec właściciela produktu i interesariuszy, lecz prognozą opartą na oszacowanym nakładzie pracy i średniej prędkości zespołu.
- Następnie deweloperzy spotykają się, aby podzielić wybrane elementy rejestru na mniejsze zadania. Najlepiej, aby te pakiety prac były dostosowane do wykonania w ciągu jednego dnia lub krócej.
- Rejestr sprintu składa się ze wspólnie uzgodnionego celu sprintu, elementów rejestru, które mają zostać zrealizowane, oraz planu ich realizacji.
- Wiele zespołów wizualizuje rejestr sprintu i pracę do wykonania na tablicy Scrum. Każdy zespół ma własną tablicę i używa różnych kolumn do dokumentowania postępów w sprincie. Zasadniczo najważniejszymi kolumnami na wszystkich tablicach powinny być następujące trzy: „Do zrobienia”, „W trakcie”, „Gotowe”.
W praktyce wiele zespołów Scrum dzieli planowanie sprintu na dwie fazy:
W pierwszej części odbywają się pierwsze cztery punkty agendy opisane powyżej. Właściciel produktu i zespół wyjaśniają kwestie: „Dlaczego ten sprint jest wartościowy?” oraz „Co zostanie wdrożone w tym sprincie?”. Deweloperzy realizują drugą część bez udziału PO i zajmują się tym, jak wykonają wybraną pracę.
Szablon agendy spotkania planowania sprintu
Potrzebujesz szablonu agendy spotkań planowania sprintu? Pobierz nasz przejrzysty i prosty szablon, aby szybko rozpocząć spotkania planowania sprintu. Znajdziesz w nim również listę kontrolną i szablon wiadomości e-mail, co zapewni dodatkową wygodę.
Czas uporządkować spotkania planowania sprintu
Dzięki temu kompleksowemu przewodnikowi możesz teraz w pełni wykorzystać sesje planowania sprintu. Jeśli ten przewodnik okazał się pomocny, polecamy również zapoznać się z naszym przewodnikiem po spotkaniach planowania projektu.
Postępując zgodnie z krokami opisanymi w tym artykule, właściciele produktów z pewnością osiągną sukces w przekształcaniu chaosu w przejrzystość i pomogą członkom swoich zespołów skutecznie zrealizować kolejny sprint. Dowiedz się więcej o strukturze Scrum i innych ceremoniach Scrum, takich jak codzienny Scrum.
Aby być na bieżąco z kolejnymi wskazówkami organizacyjnymi i materiałami dotyczącymi prowadzenia skutecznych projektów ukierunkowanych na produkt, zapraszam do zapisania się do newslettera The Digital Project Manager. Będziemy w nim nadal przedstawiać spostrzeżenia ekspertów branżowych i kierowników projektów z całego świata.
