Planowanie sprintu: spotkanie rozpoczynające sprint

Planowanie sprintu to spotkanie, które rozpoczyna sprint. Zespół uzgadnia, co ma dostarczyć, i nakreśla, w jaki sposób to zrealizuje — przekształcając fragment rejestru produktów w rejestr sprintu oraz jeden, jasno określony cel sprintu. Dobrze przeprowadzone zajmuje to kilka godzin i zapewnia zespołowi dwa tygodnie skupienia na zadaniu. Ź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 przebieg spotkania — w tym program, role, obliczenia dotyczące pojemnoś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ół stara się 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 negocjują, 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 szkic projektu pozwalający upewnić się, że zadanie jest realne.

Dane wejściowe i wyjściowe

Skuteczność planowania zależy wyłącznie od tego, co w nie 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ń do realizacji w ramach sprintu, w które zespół naprawdę wierzy.

Ocena 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 — w przewodniku po szacowaniu można przeczytać, dlaczego w tym przypadku punkty są lepszym rozwiązaniem niż czas.

Rodzaj awarii, na który należy zwrócić uwagę

Przeładowanie pracą. Zespoły planują wykorzystanie 100% teoretycznej wydajności, zapominając, że wskaźnik velocity uwzględnia już czas poświęcony na spotkania, przerwy w pracy oraz nieobecność pracownika w czwartek. Należy planować wydajność, a nie liczyć na szczęście: plan, który zespół realizuje do końca, buduje zaufanie, podczas gdy plan, z którego zespół cicho rezygnuje, to zaufanie stopniowo niszczy.

Kolejną wskazówką jest plan oparty na niedopracowanym backlogu. Jeśli planowanie zamienia się w sesję wyjaśniania i dzielenia zadań, oznacza to, że dopracowanie 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?

Należy przeznaczyć na to około dwóch godzin tygodniowo w ramach sprintu — a więc maksymalnie cztery godziny w przypadku sprintu trwającego dwa tygodnie 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 oraz 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 nie biorą w niej udziału.

Jaka jest różnica między celem sprintu a listą zadań do wykonania w ramach sprintu?

Cel sprintu to jedno zdanie wyjaśniające, dlaczego warto przeprowadzić dany sprint — jest to wynik, do którego zespół się zobowiązuje. Backlog sprintu to zbiór elementów 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ę jak zespół zdobywa nową wiedzę.