Dzień 11 – Planowanie Sprintu

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Planowanie Sprintu ma dwa cele:

1. Uzgodnić cel sprintu.
2. Stworzyć plan jego realizacji.

Przyjrzyjmy się bliżej regułom i dobrym praktykom regulującym oba te aspekty:

Uzgodnić cel sprintu

• Ustalenie celu sprintu rozpoczyna się od wyjaśnienia przez Właściciela Produktu aktualnych priorytetów i omówienie ich z zespołem wraz z możliwymi rozwiązaniami.
• Aby planowanie mogło przebiegać sprawnie Backlog Produktu powinien być GOTOWY. Jeśli nie jest, to możemy dopracować wybrane historyjki na bieżąco. Jednak jeśli zdarza się to często to powinniśmy więcej inwestować w Pielęgnację Backlogu (Backlog Grooming).
• Dla każdej historyjki powinniśmy wiedzieć co dokładnie będzie oznaczało jej zrealizowanie. Wnioski z dyskusji na ten temat powinny być zwięźle ujęte w formie Kryteriów Akceptacji, a standardy pracy wspólne dla wszystkich historyjek w Definicji Ukończenia (Definition of Done).
• Niedokończone historyjki z poprzedniego sprintu nie przechodzą automatycznie do następnego, lecz wracają do Backlogu Produktu. Być może nadal są priorytetowe i zostaną ponownie wybranie, ale nie koniecznie.
• Oprócz listy historyjek przyjętych do realizacji warto ustalić pojedynczy cel sprintu, który da zespołowi wizję wartości, wiążącą w spójną całość wszystkie historyjki.
• Wszystkie osoby, które biorą udział w pracach rozwojowych biorą też udział w planowaniu sprintu: od analityków, przez programistów, testerów, administratorów baz danych, projektantów interfejsu użytkownika, dokumentalistów i przedstawicieli wszystkich innych specjalności niezbędnych, żeby wytworzyć gotowy produkt.
• Decyzja o przyjęciu do realizacji wybranych historyjek należy do całego zespołu. Nie do Właściciela Produktu. Nie do Scrum Mastera. Nie do zewnętrznego Project Managera, ani nawet do Prezesa, gdyby ten chciał się pojawić na planowaniu.
• Decyzja ta powinna być zrodzona z konsensusu . Głosowanie narzucające wszystkim wolę większości nie prowadzi do zdrowej współpracy zespołowej.
• Wiele zespołów, które wcześniej pracowały nad wielomiesięcznymi projektami, zmaga się z pytaniem: Jak zmieścić wszystkie niezbędne prace wewnątrz krótkiego sprintu? Rozwiązaniem jest wybieranie mniejszych celów. Czasem lepiej zapytać “Co możemy dostarczyć w sprint?” niż “Jak podzielić naszą pracę na sprinty?“.
• Dostarczanie gotowych funkcjonalności powinno zacząć się od pierwszego sprintu. Architekturę aplikacji i inne wspólne elementy projektu przygotujemy przy okazji dostarczenia – być może bardzo prostej – ale konkretnej wartości.
• Planując prace w sprincie warto uwzględnić ulepszenia zaplanowane na ostatniej retrospekcji.

Stworzyć plan realizacji

• Po wyborze i omówieniu najpilniejszej historyjki (lub kilku) następnym krokiem jest przygotowanie planu jej realizacji.
• Plan powinien uwzględniać wszystkie prace niezbędne do zrealizowania historyjki zgodnie z Kryteriami Akceptacji i Definicją Ukończenia.
• Mimo tego, że staramy się od razu stworzyć kompletny plan, musimy liczyć się z tym, że w trakcie sprintu pojawią się dodatkowe zadania, niezbędne do realizacji wybranych historyjek. Według współtwórcy Scrum Kena Schwabera może to być nawet 40% wszystkich zadań.
• W trakcie planowania podejmowane są decyzje techniczne niezbędne do przyjęcia historyjek do realizacji i rozpoczęcia prac. W razie potrzeby dalsze projektowanie jest zadaniem wewnątrz sprintu.
• Powinniśmy unikać projektowania rozwiązań dla historyjek na kolejne sprinty. Zaburza to bieżący sprint (to dodatkowa praca poza realizacją aktualnie wybranych historyjek) i grozi zmarnowaniem włożonego w projektowanie wysiłku, jeśli zaprojektowana historyjka zostanie potem wyrzucona z backlogu.
• Jeśli podczas planowania brakuje nam wiedzy niezbędnej do przyjęcia historyjki to zamiast całej historyjki możemy rozważyć przeprowadzenie eksperymentu technicznego (spike) pozwalającego rozstrzygnąć wątpliwość.
• Nie przypisujemy zaplanowanych zadań do konkretnych osób, z góry na cały sprint. Każda osoba bierze kolejne zadania zgodnie ze swoimi możliwościami dopiero wtedy, gdy dokończy poprzednie zadania. Zwykle pojedyńcza osoba nie powinna mieć przypisanych do siebie więcej niż dwóch zadań na raz.
• Plan realizacji historyjek, czyli Backlog Sprintu, powinien umożliwiać śledzenie postępów w rytmie dziennym. Dlatego zadania powinny być oszacowane i żadne z nich nie powinny znacznie przekraczać jednego dnia.
• Im prostsze szacowanie pozwoli utrzymać przejrzystość w sprincie tym lepiej. Zamiast szacowania zadań w godzinach możemy ograniczyć się do trzech możliwości: “tyle co nic“, “pół dnia” i “cały dzień” albo rozbijać całą pracę na podobne do siebie kawałki i po prostu śledzić  liczbę pozostałych zadań.

Na koniec ważna reguła:

• Planowanie Sprintu jest ograniczone w czasie (do 4ch godzin dla 2-tygodniowego Sprintu). Nie powinniśmy przedłużać tego spotkania, nawet jeśli nie zdążyliśmy wszystkiego do końca zaplanować. W takiej sytuacji mamy dwie możliwości:  zaplanować kolejne, ograniczone w czasie spotkanie na następny dzień lub rozpocząć pracę i uzupełniać listę zadań na bieżąco.

Pytanie do Was:

Każdy zespół nieco inaczej prowadzi Planowanie Sprintu. Jakie są Wasze doświadczenia? Podzielcie się w komentarzach.