Planowanie sprintu: spotkanie rozpoczynające sprint
Planowanie sprintu to spotkanie, które rozpoczyna sprint: zespół uzgadnia cel sprintu i przekształca elementy rejestru zadań w plan, który, jego zdaniem, jest możliwy do zrealizowania.
Planowanie sprintu to spotkanie, które rozpoczyna sprint. Zespół uzgadnia, co ma zostać zrealizowane, oraz nakreśla sposób realizacji, przekształcając fragment rejestru produktów w rejestr sprintu oraz jeden, jasno określony cel sprintu. Dobrze przeprowadzone planowanie zajmuje kilka godzin i zapewnia zespołowi dwa tygodnie skupienia na zadaniach. Źle przeprowadzone staje się jedynie ćwiczeniem polegającym na wypełnianiu listy zadań, a zespół spędza resztę sprintu na cichym renegocjowaniu ustaleń.
Niniejszy rozdział stanowi podsumowanie dotyczące samego przebiegu ceremonii. Pełny opis przebiegu spotkania (porządek obrad, role, obliczenia dotyczące wydajności oraz przykłady celów sprintu wraz z obliczeniami) można znaleźć w kompletnym przewodniku po planowaniu sprintu.
Miejsce planowania w cyklu
Planowanie sprintu jest pierwszą z ceremonii agile, a jego wynik stanowi punkt odniesienia dla wszystkich pozostałych. Podczas codziennego spotkania stand-up weryfikuje się postępy w realizacji celu sprintu ustalonego właśnie tutaj; podczas przeglądu sprintu sprawdza się, czy zespół zrealizował ten cel. Jeśli planowanie zostanie przeprowadzone nieprawidłowo, pozostała część sprintu zostanie poświęcona na naprawianie błędów.
Na jakie pytania odpowiada planowanie: dlaczego, co, jak
W „Przewodniku po Scrumie” spotkanie opiera się na trzech pytaniach (dlaczego ten sprint jest wartościowy, co można zrobić oraz w jaki sposób zostanie to zrealizowane), a kolejność tych pytań ma znaczenie.
Najpierw ustalcie dlaczego. Cel sprintu, który można sformułować w jednym zdaniu, jest wart więcej niż lista zadań, których nie da się zrealizować. To właśnie ten cel zespół chroni, gdy w trakcie sprintu plan zderza się z rzeczywistością; zakres dostosowuje się do niego, a nie odwrotnie.
Następnie co: właściciel produktu przedstawia priorytety, programiści wybierają zadania, które ich zdaniem są w stanie zrealizować, a obie strony prowadzą negocjacje, aż do osiągnięcia porozumienia, któremu obie strony ufają. A teraz jak: programiści dzielą najważniejsze zadania na plan wystarczający do rozpoczęcia pracy: nie jest to wykres Gantta, a jedynie projekt na tyle szczegółowy, by mieć pewność, że zadanie jest realne.
Dane wejściowe i wyjściowe
Skuteczność planowania zależy wyłącznie od tego, ile w niego włożysz.
- Dane wejściowe: dopracowany rejestr zadań (pozycje już wyjaśnione i oszacowane pod względem nakładu pracy), zdolność produkcyjna zespołu na ten sprint oraz ocena aktualnej prędkości.
- Wyniki: cel sprintu oraz lista zadań sprintu, w które zespół rzeczywiście wierzy.
Określanie wielkości zadania odbywa się na spotkaniu. Większość zespołów szybko osiąga wspólną ocenę wielkości zadania za pomocą planning poker, zamiast spędzać godziny na dyskusjach. Proszę zapoznać się z przewodnikiem po szacowaniu, aby dowiedzieć się, dlaczego w tym przypadku punkty są lepszym rozwiązaniem niż czas.
Tryb awarii, na który należy zwrócić uwagę
Przeładowanie zobowiązaniami. Zespoły planują wykorzystanie 100% teoretycznej wydajności, zapominając, że wskaźnik prędkości (velocity) uwzględnia już spotkania, przerwy w pracy oraz nieobecność pracownika w czwartek. Należy planować wydajność, a nie pokładać nadzieję: plan, który zespół realizuje, buduje zaufanie, podczas gdy plan, z którego zespół cicho rezygnuje, je niszczy. Jeszcze poważniejszą porażką jest sytuacja, w której oszacowanie przedstawione przez zespół zostaje przytoczone jako obietnica, której nigdy nie złożył, przekształcone w zobowiązanie i wykorzystane przeciwko niemu – i właśnie w tym momencie planowanie przeradza się w teatr agile.
Kolejną wskazówką jest plan oparty na niedopracowanym backlogu. Jeśli planowanie zamienia się w sesję wyjaśniania i dzielenia zadań, oznacza to, że dopracowywanie backlogu nie ma miejsca. Należy to naprawić na wcześniejszym etapie, a planowanie przebiegnie spokojnie.
Najczęściej zadawane pytania
Jak długo powinno trwać planowanie sprintu?
Proszę zaplanować na to około dwóch godzin tygodniowo w ramach sprintu, czyli maksymalnie cztery godziny w przypadku sprintu dwutygodniowego i maksymalnie jeden pełny dzień w przypadku sprintu trwającego miesiąc. Jeśli planowanie rutynowo kończy się w ostatniej chwili, oznacza to, że lista zadań do wykonania została przekazana w stanie nieopracowanym, a zespół zajmuje się jej dopracowaniem, co powinien był zrobić wcześniej.
Kto bierze udział w spotkaniu planowania sprintu?
Cały zespół Scrum: programiści, właściciel produktu i scrum master. Właściciel produktu określa priorytety i uzasadnienie; programiści decydują, jakie zadania są w stanie realistycznie podjąć i w jaki sposób je zrealizują; scrum master dba o to, by sesja odbywała się w wyznaczonym czasie i była skoncentrowana na zadaniu. Uczestnicy zewnętrzni nie biorą udziału w sesji.
Jaka jest różnica między celem sprintu a zaległościami sprintu?
Cel sprintu to jedno zdanie wyjaśniające, dlaczego warto przeprowadzić dany sprint: jest to wynik, do którego realizacja zespół się zobowiązuje. Backlog sprintu to zbiór pozycji i zadań, które według zespołu pozwolą osiągnąć ten cel. Cel jest ustalony na czas trwania sprintu; backlog może się zmieniać w miarę zdobywania przez zespół nowych informacji.