Planowanie Sprintu to jedno z ważniejszych wydarzeń w Scrumie. W zależności od tego, jak podejdziemy do planowania, Sprint może zakończyć się sukcesem lub porażką. Niestety, wiele Zespołów Scrumowych podchodzi do planowania pracy w sposób bardzo powierzchowny, co skutkuje zwykle niespodziankami i problemami w trakcie Sprintu. W artykule opisuję prostą technikę tworzenia planu dostarczenia Sprintu, opartą na wizualnym przedstawianiu konkretnych kroków do wykonania.
Co jest nie tak z Planowaniem Sprintu?
Zwykle zespoły nie przykładają się dostatecznie dobrze do zaplanowania pracy w Sprincie. To, że przesuniesz w JIRA elementy z Backlogu Produktu do Backlogu Sprintu nie znaczy jeszcze, że masz plan dostarczenia Sprintu. Jest to dla mnie wyraźny przykład na to, jak procesy i narzędzia potrafią przysłonić ludzi oraz interakcje między nimi.
Wizualna technika przygotowania planu dostarczenia Sprintu
To, co zwykle proponuję zespołom w takich sytuacjach, to prosta technika wizualnego przedstawienia planu pracy, którą opisałem krótko w swojej książce, jako pomysł na lepsze zaplanowanie Sprintu. Ze względu na skuteczność tego podejścia, postanowiłem przygotować szerszy opis krok po kroku, wzbogacony o pokazanie na zdjęciach, jak to wygląda w praktyce.
Co potrzebujemy do przygotowania takiego planu?
- Zespół Deweloperski, najlepiej w pełnym składzie, tak aby można było spojrzeć na plan z perspektywy osób o różnych kompetencjach
- Jedną godzinę czasu. Nie przygotujemy takiego planu w 5 minut, jedną nogą będąc już poza salką, a w myślach jedząc już drugie śniadanie. Na bazie moich doświadczeń, na przygotowanie planu potrzeba zwykle około godziny. Poświęcenie takiej ilości czasu w kontekście jedno lub dwu-tygodniowego Sprintu to żaden koszt, jeśli porównamy to do efektów, jakie możemy uzyskać
- Tablica suchościeralna, flipchart, ściana lub folia elektrostatyczna, jako płaszczyzna przygotowania planu. Im większa dostępna przestrzeń, tym plan będzie bardziej czytelny.
- Kilka kolorów mazaków, co pozwala wizualnie wyróżnić konkretne elementy planu
Krok 1. Narysuj macierz ludzie/dni Sprintu
Poziomo, w osi X, wypisz dni w nadchodzącym Sprincie, a pionowo, w osi Y – imiona członków Zespołu Deweloperskiego. Powstanie w ten sposób macierz, która obrazuje wizualnie przestrzeń, która jest dostępna dla zespołu w trakcie bieżącego Sprintu.
Krok 2. Nanieś na macierz nieobecności członków Zespołu Deweloperskiego
W kolejnym kroku z macierzy wykreśl dni, w których konkretne osoby są niedostępne. Tutaj zwykle stosuję granulację “pół dnia” – czyli albo wykreślam cały dzień, albo pierwszą lub drugą jego połowę. Jest to pewne uproszczenie, jednak na bazie moich doświadczeń wystarczające, aby umożliwić sensowną dyskusję na temat planu dostarczenia Sprintu.
Krok 3. Zaplanuj pracę
Mając już jasność, co do dostępności osób, zachęć członków zespołu do wypełnienia macierzy pracą do zrealizowania, zaczynając od tematów najważniejszych z punktu widzenia realizacji Celu Sprintu. W zależności od sposobu pracy zespołu, wpisywane są w macierz albo konkretne elementy Backlogu Produktu (najczęściej w postaci User Stories), albo zdekomponowane zadania techniczne, składające się na konkretne User Stories.
Celowo piszę o zaangażowaniu członków Zespołu Deweloperskiego do wypełnienia tej macierzy. Można by to przecież zrealizować ręką Scrum Mastera, prawda? Jednak z mojej perspektywy przygotowanie planu dostarczeniu Sprintu jest odpowiedzialnością Deweloperów, stąd dbam o to, żeby to oni, własnymi rękoma, przygotowali ten plan. W praktyce, gdy uczę zespół tej techniki, w pewnym momencie przekazuję mazak jednej z osób, z prośbą zaznaczanie na macierzy pracy, którą właśnie omawialiśmy. Na zasadzie: “Tomek, czy mógłbyś dopisać do planu zadanie, które właśnie omówiliśmy?”. Nie spotkałem się z sytuacją, w której usłyszałbym odmowę.
Wiele zespołów na etapie planowania dodaje sobie niewielką rezerwę czasu na sytuacje nieprzewidziane. Powoduje to, że plan nie jest przygotowany “na styk”, tylko pozostaje na końcu Sprintu przestrzeń na sytuacje losowe. Wielkość tej rezerwy zależy od zespołu i jest określana empirycznie, na bazie wcześniejszych doświadczeń.
Krok 4. Podsumuj przygotowany plan pracy
Gdy Zespół Deweloperski skończy wypełnianie macierzy, warto upewnić się, że całościowy plan jest wykonalny i zrozumiały dla wszystkich. To, co zwykle robię w tym momencie, to proszę dowolną osobę z zespołu o opowiedzenie, jak z jej perspektywy wygląda plan na Sprint. Często podczas tego ćwiczenia wychodzą drobne nieścisłości oraz nieco inne rozumienie tego, czym faktycznie będzie zajmował się zespół. W przypadku wykrycia takich sytuacji, dokonujemy korekty planu.
Co dalej z tym planem?
Zwykle Zespoły Deweloperskie zabierają ten plan ze sobą do przestrzeni, w której pracują. Pozwala im to w łatwy sposób wrócić do niego w dowolnym momencie. Należy pamiętać, że największą wartością z tego ćwiczenie jak sama czynność planowania — układanie kolejności, dyskusja o ryzykach, zależnościach czy możliwościach zespołu. Odkrywana jest wiedza, która bez tej dyskusji, nie wyszłaby na światło dziennie i nie wzbogaciłaby zespołu. Sam plan podlega najczęściej modyfikacji, zwykle co najmniej podczas Codziennego Scruma, co jest skutkiem pracy w złożonym środowisku oraz praktycznego stosowania inspekcji oraz adaptacji.
Dlaczego warto spróbować wizualnego planowania Sprintu?
Istnieje kilka namacalnych korzyści, które powodują, że warto spróbować tej konkretnej techniki:
- Powstaje faktyczny plan. Ćwiczenie to może dać bardzo konkretną korzyść w zespołach, które dotychczas tego nie robiły, poprzez znaczące zwiększenie szans na realizację Celu Sprintu
- Wizualne przedstawiamy plan pracy. Pomaga to uniknąć nieporozumień (“a ja myślałem, że jak mówiłeś X, to znaczyło to, że …”) oraz użyć większej ilości zmysłów (słuch + wzrok) w celu upewnienia się, że mamy wspólne zrozumienie tematów.
- Wiele tematów “wychodzi” podczas planowania. Są to zwykłe tematy, które nigdy nie wyszłyby na powierzchnię na tak wczesnym etapie, gdy jeszcze możemy coś z tą wiedzą zrobić.
- Faktyczny nacisk na “ludzi oraz interakcje”. Żeby powstał ten plan, grupa osób musi usiąść razem i zacząć rozmawiać. Elektroniczne narzędzia nie generują zwykle aż tak bogatych i głębokich interakcji.
- Plan jest dobrym punktem odniesienia podczas Codziennego Scruma. Może to mieć szczególne znaczenie dla zespołów, które podczas tego 15 minutowego spotkania tylko rozmawiają, nie wspierając się wizualizacją aktualnego przebiegu prac. Posiadanie takiego planu pozwala wskazać palcem konkretne zadanie, zobaczyć zaplanowane kolejne kroki oraz kto je wykonuje czy ocenić wizualnie, jak dobrze nam idzie realizacja Celu Sprintu.
- Łatwo wyłapać wąskie gardła. Często obserwuję sytuację, w której osoby o kompetencjach programistycznych rozplanowują sobie pracę w taki sposób, że osoby o kompetencjach testerskich dostają pracę do przetestowania dzień przed końcem Sprintu. Możliwość dostrzeżenia tego problemu jest zwykle dobrym punktem startowym do rozmowy o likwidowaniu wewnętrznych silosów w zespole (“ja jestem programistą, nie testuję”).
Jakie są zagrożenia tak przygotowanego planu?
Realizując to ćwiczenie, warto mieć z tyłu głowy pewne ryzyka, związane z takim sposobem planowania pracy.
- Powstaje dosyć sztywny plan. A przynajmniej tak on może zostać odebrany przez zespół. Nie każdy podchodzi do takiego planu elastycznie i obserwowałem sytuacje, w których zespoły podążały za planem, zamiast traktować go raczej jako wskazówkę. Warto zadbać o to, aby przygotowany plan nie przysłonił zdrowego rozsądku oraz aby nie wykluczył poddawania planu regularnej inspekcji oraz adaptacji.
- Prawo Parkinsona. Mówi o tym, że praca zajmie tyle czasu, ile na nią przeznaczymy. Często mniejsza dostępność czasu na konkretną pracę prowadzi do tych samych rezultatów. Stąd, jako że rozkładamy pracę na dni tygodnia, warto z rozwagą podchodzić do oszacować, czy potrzebujemy pół, jeden czy dwa dni, aby ją zrealizować.
- Przełożenie Story Pointów na czas. Zespoły, który zdecydowały się na relatywne metody szacowania, mogą czuć się nieswojo, układając pracę -wcześniej wycenioną przez porównywanie – w czasie. Może to doprowadzić do niebezpiecznych uproszczeń, np. “Jeden Story Point to pół dnia”. Pomimo tego moje doświadczenia są takie, że dla zespołów z ugruntowanym zrozumieniem, czym jest relatywne szacowanie, problem ten nie jest groźny.
Podsumowanie
Wizualny plan dostarczenia Sprintu to dobra technika, aby przejść od ogólnikowego planowania na wyczucie do stworzenia namacalnego planu. W szczególności poleciłbym ją zespołom, które nie mają doświadczenia w przygotowywaniu realnych planów na Sprint. Warto spróbować tej techniki, chociażby dlatego, żeby poznać nowy, inny sposób wykonywania tej samej czynności i samodzielnie ocenić, czy przynosi korzyści.
Jakie znacie inne metody planowania? Podyskutujmy w komentarzach.
Posłuchaj też 41. odcinka podcastu Porządny Agile – Wizualizacja pracy w Sprincie.
Polecamy Ci też do posłuchania odcinek 71 – Porządny Backlog Produktu
Photo by rawpixel on Unsplash