Planowanie Sprintu w Scrumie

Bez Planowania Sprintu, nie ma Sprintu, czyli nie ma „serca Scruma”. To z pozoru proste Wydarzenie Scrumowe przysparza często wielu problemów i rodzi mnóstwo pytań. Gdyby tego było mało, najnowsza wersja Scrum Guide’a z listopada 2020, rozszerzyła sekcję dotyczącą Planowania o dodatkowy element. O co w nich chodzi i jak podejść w praktyce do Sprint Planningu?

Dlaczego Sprint ma wartość?

Jedną z kluczowych odpowiedzialności Product Ownera jest szeroko rozumiana maksymalizacja wartości Produktu budowanego przez Zespół. Robi to przykładowo poprzez podejmowanie właściwych decyzji odnośnie kolejności realizacji zagadnień z Backlogu Produktu. Te najbardziej wartościowe umiejscowione są na samej górze listy. Odpowiednie ułożenie kolejności to jednak nie wszystko.

Planowanie Sprintu rozpoczyna się od zaprezentowania propozycji ze strony PO i odpowiedzi na pytanie:

DLACZEGO realizacja zbliżającego się Sprintu przyniesie wartość ?

To właśnie pytanie o przyczynę zostało dodane w najnowszej aktualizacji „Przewodnika po Scrumie”.

Następnym krokiem jest dyskusja całego Zespołu Scrumowego, której efektem jest wypracowanie Celu Sprintu. Realizacja kolejnych Celów Sprintu przybliża z kolei do osiągnięcia Celu Produktu. Narzędziem wspierającym ten proces może być popularna technika wyznaczania celów SMART.

Często spotykanym antywzorcem jest natomiast sytuacja, w której Product Owner przychodzi na Planowanie z gotowym Celem Sprintu, zleca jego realizację i nie podejmuje żadnego dialogu z Zespołem. Niestety miałem nie raz okazję pracować z tego typu osobami, które pokazywały stworzony przez siebie wcześniej Cel, obwieszczały start Sprintu sformułowaniem „GO DO” i wychodziły 😉 Chyba nie musze dodawać czy takie iteracje się udawały czy nie.

Pamiętaj, że ostateczne brzmienie Celu powinno być efektem dyskusji i współpracy całego Zespołu Scrumowego. PO przychodzi ze wspomnianym pierwszym wsadem i wizją. Developerzy zderzają ten pomysł z różnymi ograniczeniami i urealniają go. Scrum Master natomiast może facylitować całe Wydarzenie i służyć Zespołowi podsuwając użyteczne praktyki formułowania Celów.

Co może zostać ukończone w Sprincie?

Temat drugi Planowania Sprintu to niezmiennie odpowiedź na pytanie:

CO Zespół Scrumowy jest w stanie ukończyć w nadchodzącej iteracji.

Na tym etapie Developerzy wybierają elementy Backlogu Produktu, których realizacja spowoduje osiągnięcie Celu Sprintu. Podczas dobierania również odbywa się dyskusja z Product Ownerem, który cały czas bierze aktywny udział w wydarzeniu. Aby proces ten przebiegł sprawnie, Backlog Produktu powinien być odpowiednio zadbany i uporządkowany. Po więcej porad jak to robić odsyłam do artykułu o Backlog refinemencie.

Aby dobrze oszacować ilość pracy jaką Zespół może wykonać w Sprincie przydatne będzie posiadanie pewnych historycznych danych. Z pomocą przyjdzie nam prędkość zespołu (Velocity) i planowana obecność czasowa Developerów w Sprincie (Capacity).

Jak policzyć Velocity Zespołu Scrumowego?

Velocity czyli po prostu prędkość Zespołu. Jest to suma estymat wszystkich elementów Backlogu Produktu zaplanowanych na dany Sprint, nad którymi prace zostały w pełni ukończone. Najczęściej podaje się ją w Story Pointach, ale nie jest to konieczne. Zespoły niekorzystające z tej techniki często liczą swoją prędkość po prostu jako ilość zrealizowanych wymagań.

Posiadając dane z kilku minionych iteracji wnioskujemy, że kolejne będą analogiczne. Na tej podstawie zakładamy Velocity zespołu na nadchodzący Sprint. Jest to tak zwana metoda „wczorajszej pogody” (ang. yesterday weather). Istnieją dwa podejścia w jej wyliczeniu.

Pierwsze z nich to po prostu najzwyklejsza w świecie średnia arytmetyczna z kilku ostatnich Sprintów. Drugie, moim zdaniem dużo lepsze, to traktowanie Prędkości jako pewnego przedziału minimum i maksimum. Przykładowo:

1. Zespół realizował średnio na przestrzeni ostatnich 5 Sprintów około 100 Story Pointów.
   
   • Oczywistym jest zatem, że zaplanowanie przykładowo 150 nie ma większego sensu, a realizacja aż o 50% więcej graniczy z cudem.
   • Z kolei zaplanowanie jedynie 50 punktów to raczej mało ambitny plan.
     
2. Zespół realizował przez ostatnie 5 Sprintów od 85 do 105 Story Pointów na Sprint.
   
   • Do kolejnego Sprintu możemy przyjąć wariant bardziej pesymistyczny, bliższy 85 lub bardziej optymistyczny, bliżej 105 punktów.
   • W obu przypadkach, zaplanowanie prac na dowolną liczbę SP z przedziału 85-105 ma duże prawdopodobieństwo sukcesu.

Velocity vs. Capacity Zespołu

Jeżeli skład Zespołu nie zmienia się co Sprint to sytuacja z powyższego przykładu wydaje się oczywista. Jak jednak przeliczyć i zaplanować prędkość w sytuacji, gdy któryś z Developerów idzie na urlop? Wówczas z pomocą przyjdzie nam tak zwane Capacity czyli najprościej rzecz ujmując obecność Developerów wyrażona przykładowo w procentach.

Załóżmy, że przy pełnej obsadzie (100% Capacity) zespół realizuje 200 Story Pointów. W sezonie urlopowym niedostępna jest połowa członków zespołu, a zatem planujemy jedynie 50% czyli około 100 Story Pointów.

Pamiętaj jednak, że metoda ta jest bardzo dużym uproszczeniem i nie można traktować jej jak wyroczni. Zapewne zdarzą się też Sprinty, w których pomimo braku pewnych Developerów, zespół dostarczy więcej niż powinien lub odwrotnie. Może to wynikać chociażby z nierównych kompetencji pomiędzy Developerami.

Liczenie Capacity i Velocity ma nam jedynie pomóc w urealnieniu planu na Sprint, bazując na dotychczasowym empiryzmie, który jest podstawą Scruma. Należy zatem podchodzić do wyliczeń z pewną rezerwą i otwartością na mogące wystąpić zmiany.

Warto przytoczyć też w tym momencie jedną z zasad Manifestu Agile, która mówi, że podstawową miarą postępu jest działające oprogramowanie. Pamiętaj zatem, że liczenie i stopniowe zwiększanie Velocity nigdy nie może być celem samym w sobie. Zależy nam na wartościowym i użyteczny Produkcie, a nie pokazaniu, że Zespół się napracował i dostarczył dużo Story Pointów.

W jaki sposób Zespół wykona pracę w Sprincie?

Trzecia i ostatnia część Planowania Sprintu to odpowiedź na pytanie:

JAK Zespół zrealizuje prace zaplanowane na Sprint?

Wybrane na wcześniejszym etapie elementy Backlogu Produktu uzupełniane są o konkretny plan ich realizacji. Developerzy najczęściej tworzą go poprzez dzielenie większych kawałków na mniejsze, konkretne zadania do wykonania. Warto podkreślić, że sami decydują o sposobie podziału i realizacji zadań. Nikt nie może im go narzucić i wskazać jak mają doprowadzić do przekształcania elementów Backlogu w wartościowe Przyrosty Produktu. Więcej w tym temacie w artykule jak dzielić Historyjki Użytkownika.

Kiedy kończymy Planowanie Sprintu?

Ostatecznym efektem Planowania Sprintu, które nie powinno przekroczyć 8 godzin w przypadku Sprintu trwającego miesiąc, jest stworzenie Backlogu Sprintu.
W jego skład wchodzą Cel Sprintu wraz z wybranymi do realizacji elementami Backlogu Produktu i planem ich dostarczenia. Backlogiem Sprintu zarządzają dalej wyłącznie Developerzy.

Na koniec warto podkreślić, że zakres Sprintu nie jest „zamrożony” na stałe. W miarę postępu prac, Developerzy często będą dodawać nowo odkryte zadania, usuwać inne, czy też zmieniać kolejność ich realizacji. Jest to zjawisko całkowicie normalne. Jedynym warunkiem jest to, aby wspomniane działania nie wpłynęły negatywnie na osiągnięcie założonego Celu Sprintu. Liczy się efekt końcowy.