10 wskazówek na Planowanie Sprintu

Planowanie Sprintu jest pierwszym wydarzeniem w Sprincie. Plan, który w tym czasie utworzy Zespół Scrumowy powinien być planem na osiągnięcie sukcesu, ale często zdarza się, że jest planem osiągnięcia porażki. Zespoły są przekonane, że planowanie przebiegało dobrze, a później są zaskoczone, że nie ma Przyrsotu na koniec Sprintu, albo zrobiły coś, co nie było Celem Sprintu. Nie wszystko da się zaplanować. Zbyt szczegółowe Planowanie Sprintu też nie jest dobrym pomysłem. Jest jednak szereg praktyk pozwalających zwiększyć szansę sukcesu. Zobaczmy najpierw według Scrum Guide powinno być wynikiem planowania.

Product Owner przychodzi z negocjowalnym pomysłem

Przychodząc na Planowanie Sprintu Product Owner powinien mieć już pomysł na Cel Sprintu. Nie zapominajmy, że duża część pracy z Backlogiem Produktu odbywa się poza spotkaniami Scrumowymi. Kiedy Product Owner powinien mieć już jakiś pomysł na kolejny Sprint? Ostatnim dobrym momentem jest Przegląd Sprintu gdzie mówi Interesariuszom co mniej więcej będziemy robili w kolejnym Sprincie. Lepszym momentem byłby już Product Backlog Refinement w poprzednim Sprincie, bo Zespół Deweloperski musi określić, czy elementy Product Backlog na kolejny Sprint są gotowe.

Mocny Cel Sprintu

Od wielu lat klasycznym sprawdzeniem czy Cel jest dobry jest metoda SMART. Pisałem o tym w innym poście, wiec tutaj tylko zostawię link. T w SMART jest w Scrum oczywiste, bo mamy ograniczenie timeboxem Sprintu.
Do Celu Sprintu zastanówcie się nad:

• Na co wydajemy pieniądze? Kosztuje mnie to kilkadziesiąt tysięcy i co z tego będę mieć?
• Czy to jest wartość dla klienta?
• Czy to jest Przyrost Produktu?
• Co pokażemy na Przeglądzie Sprintu?
• Czy w Celu Sprintu mamy czasownik? Umożliwić, dostarczyć, rozwiązać, zdecydować?

Gotowe do pracy w Sprincie

Czy ten element Backlogu Produktu jest Gotowy do Sprintu? Jeśli nie, to czy poradzimy sobie z tym w Sprincie? Czy decyzja A czy B zostanie szybko podjęta? Czy dorysujemy sobie brakujące ekrany? Czy inny zespół na pewno dostarczy rzeczy na czas?

Nic tak skutecznie nie sabotuje pracy w Sprincie jak praca nad czymś czego się nie rozumie do końca. Planowanie Sprintu w takim przypadku się przedłuża. Zespół Deweloperski nie czuje się pewnie z planem na Sprint. Jeśli Zespół Deweloperski nie czuje, że uda im się wykonać pracę i dostarczyć Przyrost, to nie ma sensu w pełni się zaangażować w tą pracę. I tak się nie uda i tak się nie uda.

Ustalcie realny Cel Sprintu wspólnie

Product Owner przychodzi z propozycją, ale wspólnie z Zespołem Deweloperskim dochodzi do wersji ostatecznej. Jeśli Cel jest nierealny, to może zróbmy mniejszy Cel? Może bardziej skonkretyzujmy co Product Owner przez to rozumie. Dobry Cel Sprintu daje nadal swobodę działania, swobodę wyboru poszczególnych PBI lub ich zmiany.

Ostatnio mieliśmy przypadek gdzie zaczęliśmy od celu „Zrobić UATy”. Tak, wiem paskudny Cel Sprintu i wyraźny znak, że trzeba podciągnąć Definition of Done. Jednak póki co testy UAT są poza zespołem. Czy zatem taki Cel Sprintu jest dobry? Zespół nie robi UAT, zespół poprawia błędy z UAT. Czy „Poprawianie błędów z UAT” to cel? Skończyliśmy na „Przygotować paczkę gotowa do wdrożenia na produkcję”.

Nie planujcie 100% pojemności

W niektórych organizacjach nadal pokutuje kultura maksymalizacji zajętości (ang. capacity unilization). Trzeba zrobić planowanie tak, żeby na pewno każdy miał zajęte 100% czasu. Widziałem tablice z podziałem na nazwiska i sprawdzanie w Jira ile kto ma godzin na sobie. Takie podejście spowoduje, że nie ma marginesu błędu.

Praca w Spricie zawsze się wyłania. Pojawią się nowe zadania, inne ulegną zmianie. To co robimy to złożona praca, więc nie da się dobrze przewidzieć wszystko z góry na 100% na Sprint. Kiedy już wydarzy się coś nieoczekiwanego nie mamy pola manewru i praca od razu wykroczy poza czas trwania Sprintu.

Stretch Goal, czyli branie więcej niż Zespół Deweloperski może zrobić jest jeszcze gorszą praktyką, więc nawet o tym juz tutaj nie będę pisał. Jeśli praca idzie szybciej, to Zespół Deweloperski przyjdzie do Product Ownera po więcej pracy.

Zastanówcie się jak wykonać pracę i zróbcie notatki

Zespół Deweloperski powinien być w stanie wytłumaczyć jak wykona pracę, która jest potrzebna do osiągnięcia celu Sprintu. Żeby to zrobić trzeba przedyskutować kilka rzeczy i podjąć decyzje. Może trzeba wspólnie narysować algorytm, kawałek architektury, ekran. Jakie zmiany i gdzie trzeba wprowadzić? Co potrzebujemy zrobić, żeby spełnić Definition of Done? Takie rozmowy skupiają cały zespół wokół Celu Sprintu.

Kiedy mamy czas i uwagą całego zespołu, postają dużo lepsze pomysły niż kiedy jeden deweloper próbuje samodzielnie rozwiązać problem. Warto te wszystkie decyzje i pomysły spisać. W ciagu Sprintu łatwo jest zapomnieć dobre pomysły i wymyślać koło od nowa. Nikt nie lubi długich opisów w Jira. Notatki nie musza być w formie tekstu. Zdjęcia rysunków i zapisów na tablicy wystarczą.

Zadania i szacowanie w godzinach są opcjonalną praktyką

Często tracimy dużo czasu na Planowaniu Sprintu na stworzenie wszystkich zadań i oszacowanie ich w godzinach. Stworzenie zadań dla każdego wybranego elementu nie jest wymagane przez Scrum Guide. Niektóre zespoły mają tak małe elementy Backlogu Produktu, że nawet nie ma sensu ich rozbijać na mniejsze. W większości przypadków warto jednak zobrazować sobie pracę do wykonania za pomocą konkretnych zadań. Zespól Deweloperski powinien mieć jasny plan pracy przynajmniej na kilka pierwszych dni Sprintu. Prawdopodobnie trzeba też ustalić co i kto będzie robił do pierwszego Daily Scrum. Reszta zadań może powstawać na bieżąco w ramach Sprintu.

A co z szacowaniem w godzinach? Warto się zastanowić jaką wartość dla Zespołu Scrumowego niesie szacowanie zadań w godzinach. Z punktu widzenia Product Ownera liczy się ukończenie elementu Backlogu Produktu, który jest oszacowany w abstrakcyjnej jednostce. Czyli na przykład mamy User Story, które jest oszacowane w Story Points. Po co do tego dokładać godziny? Nie ma to sensu.

A co jeśli Product Owner chciałby dowiedzieć się ile kosztuje go dany element? Znamy koszt Sprintu i oszacowaną wielkość elementu, więc łatwo można policzyć koszt jednego elementu. Nadal godziny nie są potrzebne.

Może Zespól Deweloperski potrzebuje oszacowania w godzinach? Ale po co? Może potrzebują sprawdzić czy dobrze planują? Może na początku tak, ale czy potrzebują to robić co Sprint? Może chcą narysować Sprint burndown? Można go też rysować według innej jednostki jak Story Point. Tutaj też nie ma dobrego powodu. Może ktoś chce kontrolować Zespół Deweloperski i sprawdzać czy każdy jest zajęty? To jest bardzo zły pomysł i świadczy o braku zaufania. Więc po co szacować zadania w godzinach jeśli nie ma dobrego powodu? Trochę szkoda czasu i energii.

Czy potrzebujecie bufor?

Czasem nie da się oszacować pracy ale wiadomo, że się wydarzy i trzeba ją jakoś zaplanować. Na przykład jeśli mamy zespół który zajmuje się utrzymaniem produktu, pracą bieżącą, BAU. Wiadomo, że taka praca pojawi się w Sprincie ale nie można z góry przewidzieć ile jej będzie. Nie można przewidzieć ile zleceń się pojawi czy ile wydarzy się awarii na produkcji. Jak sobie z tym poradzić na planowaniu? Jedyne co można zrobić to założyć bufor. 20%, 30%?

Taki bufor obserwujemy w trakcie Sprintu i jeżeli przekroczy 50% to wtedy można się zastanowić czy nadal realne jest osiągnięcie Celu Sprintu. Dobrze jest jasno raportować ile czasu Zespołu Deweloperskiego jest poświęcone na pracę nie związaną ze Sprintem. Jeśli to jest przeszkoda do usunięcia, to warto mieć twarde dane dla kierownictwa.

Nie przypisujcie zadań na cały Sprint do Deweloperów

Przypisywanie wszystkich zadań do Deweloperów na Planowaniu Sprintu kompletnie nie ma sensu. Zespól Deweloperski powinien planować kolejny dzień pracy na Daily Scrum w zależności od tego, co jest w danym dniu potrzebne i co wydarzyło się wcześniej. Przypisanie zadań na Planowaniu Sprintu może spowodować kilka negatywnych skutków. Jeden skutek jest taki, że każdy może zacząć interesować się tylko swoimi zadaniami i stracić cel Sprintu z pola widzenia. Filtry w Jira, tablice z podziałem na nazwiska i widget My Tasks stają się wtedy jedynym miejscem, w które Deweloper zagląda. Jak to się ma do pracy zespołowej? Drugi skutek to taki, że nie ma elastyczności albo przynajmniej jest duży opór, żeby wymieniać się przypisanymi zadaniami.

Pamiętajcie, że to tylko PROGNOZA

Zespół Deweloperski wykonuje prace nad produktem, która jest złożona. Złożona praca ma to do siebie, że jest wiele zmiennych i właściwie niemożliwe jest zbudowanie dokładnego planu wykonania tej pracy. Co za tym idzie nie można przewidzieć dokładnie będzie potrzebne i co się wydarzy w całym Sprincie. Zespól Deweloperski planuje Sprint jak najlepiej potrafi biorąc pod uwagę obecny stan wiedzy.

Niektóre szczegóły dopiero trzeba ustalić, w trakcie pracy zwykle pojawiają się nieprzewidziane okoliczności i Backlog Sprintu zmienia się w trakcie trwającego Sprintu. Bywa, że trzeba renegocjować zakres Sprintu lub poszczególnych elementów. Dlatego nie można oczekiwać, że na Planowaniu Sprintu pojawi się szczegółowy plan. Plan, który zbuduje zespół Deweloperski to jedynie prognoza, która tak samo jak prognoza pogody jest niedokładna. Czasem prognozy sprawdzają się, a czasem nie.