Jak stworzyć wizualny plan dostarczenia Sprintu?

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.

Macierz przedstawiająca osoby z Zespołu Scrumowego oraz dni tygodnia dla jednotygodniowego Sprintu - od poniedziałku do piątku.

Macierz przedstawiająca osoby z Zespołu Scrumowego oraz dni tygodnia dla jednotygodniowego Sprintu – od poniedziałku do piątku.

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.

Macierz na naniesionymi nieobecnościami - urlopy, czas zaplanowany na wydarzenia w Scrumie, udział w rekrutacjach oraz inne aktywności, które są już zaplanowane na konkretny tydzień pracy.

Macierz na naniesionymi nieobecnościami – urlopy, czas zaplanowany na wydarzenia w Scrumie, udział w rekrutacjach oraz inne aktywności, które są już zaplanowane na konkretny tydzień pracy.

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ń.

Macierz z naniesioną pracą do wykonania. Każdy kolor reprezentuje konkretne zadanie Zespołu Scrumowego.

Macierz z naniesioną pracą do wykonania. Każdy kolor reprezentuje konkretne zadanie Zespołu Scrumowego.

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.

Photo by rawpixel on Unsplash

Komentarze do wpisu: “Jak stworzyć wizualny plan dostarczenia Sprintu?

  1. Przez dłuższy czas używaliśmy takiego narzędzia jednak wad jest trochę więcej niż opisane w artykule. Wiem jak wygląda współpraca w zespołach planujących w powyższy sposób i minusy które pierwsze przychodzą mi do głowy to:

    1. Ręcznikowanie – na etapie planowania Developerzy jak zwykli Janusze w kurortach rzucali ręczniki na co ciekawsze zadania, nie zawsze zgodnie z priorytetami.

    2. To nie pomaga w tworzeniu zespołu. Jest to narzędzie które zabija pair programming, zabija kooperację.

    3. Dodawanie rezerwy? A skąd wiem ile tej rezerwy? A po co rezerwa – skoro możemy dać z siebie 100% to czemu planować na 80% – to tylko kilka pytań które zada PO.

    Obecnie używamy to TYLKO na planningu by sprawdzić czy to co mamy wycenione tak na prawdę nam się mieści do Sprintu. Potem taką tablicę od razu niszczymy bo używanie jej później w mojej opinii przyniesie więcej szkody niż pożytku.

    • Dlaczego planować buffor? Spadające bugi z produkcji zatrzymujące dopływ gotówki do firmy, „critical” na produkcji, CRka, która zajmie więcej niż się na początku wydawało, ktoś nie będzie miał racji z estymacją, praca z technikalami rozwijającymi system, etc.
      Nikt nie jest w stanie zaplanować z dokładnością 100%, gdyby się dało to po co Scrum skoro wszystko było by tak przewidywalne? To jest kwestia edukacji Product Ownerów – raczej nie jest to większym problemem.

      • Nie przedstawiłeś w mojej opinii żadnego argumentu na bufor. Proszę przekonaj mnie że bufor ma sens. Postaram się rozbić powyższe na szczegóły:

        1. „spadające bugi z produkcji” czy „critical” – to oczyw1iste w Scrum, że kiedy PO przynosi coś bardzo ważnego to renegocjujemy scope, zostawienie bufora to otwarta furtka na pompowanie Sprint Backloga, jest to fundamentalny błąd.

        2. „CRka, która zajmie więcej niż się na początku wydawało” – ta zajmuje więcej a inna mniej. Tak jak nie każde zadanie za 1SP robi się w tym samym czasie, pozwólmy potędze matematycznej średniej zadziałać bez ręcznego sterowania.

        3. „praca z technikalami rozwijającymi system” – STOP! To zespół decyduje co jest w stanie wykonać by osiągnąć cel sprintu!

        Tu nie chodzi o nie planowanie zawsze dokładne. Tu chodzi o to, że bezpieczne planowanie zawsze na 80% i z buforem tak by nigdy nie odnieść porażki jest słabe.

    • Jacek Wieczorek

      Dzięki Maciej za Twój komentarz.

      1. Problem „ręcznikowania” brzmi dla mnie jak dysfunkcja, o której warto podyskutować w zespole. Wyobrażam sobie, że podobne zachowanie może pojawiać się bez wizualnego planowania. Narzędzie wizualne w mojej ocenie tylko wyeksponowało problem.

      2. Na bazie moich doświadczeń ten sposób planowania nie wyklucza pair-programmingu.

      3. Rezerwa nie wyklucza pracy na 100%. Natomiast osobiście jestem fanem posiadania slack time’u, a nie dążenia do 100% zajętości. Jest świetna książka o tym na rynku, napisałem krótką recenzję kilka lat temu: http://agilecoaching.pl/slack-tom-demarco/.

      • Cześć,

        Masz rację odnośnie Pair programming, takie podejście całkiem go nie wyklucza i również zgadza się „ręcznikowanie” występuje bez tego boarda ale zaobserwowałem że wtedy częściej.

        Slack time – Tak. Przy czym, czy mając wolne piątki na co tylko chcesz to od poniedziałku do czwartku planujemy na 100% czy nie?

        • Jacek Wieczorek

          Maciej,

          moim zdaniem wolny piątek, czyli taki całodniowy slack, niekoniecznie da Ci to, co może Ci dać po trochę slacka porozkładanego na każdy z dni tygodnia.

          Przykładowo: jeden z Deweloperów skończył właśnie realizować element z Backlogu Produktu i jedyne czego brakuje, to testów. Osoba, która akurat ma slack time, może z marszu przeprowadzić testy i zamknąć zadanie, skracając jego lead time.

          Inny przykład: jeden z Deweloperów napotyka trudności w realizacji zadania. Jeśli mamy jako zespół slack time, to ktoś może usiąść razem z nim do tematu i pomóc mu w jego realizacji.

          • Rozumiem, jednak ponawiam pytanie, czy czas poza slack time polecasz planować w 100% czy jeszcze jednak z buforem?

  2. Ad. 2 – dlaczego zabija zespołowość? U nas traktujemy to jako osoba, odpowiedzialna za zadanie, co nie znaczy, że ma je robić samemu od początku do końca – bo się nie da skończyć User Stories w pojedynkę (w naszym przypadku) – szczególnie jak dostarczamy modelowo wskrośfunkcjonalnie. Poza tym jaki problem przypisać na takiej kartce dwie osoby do jednego zadania i posadzić ich do Pair Programmingu? Rozwiniesz trochę tą kwestie?

    • „Poza tym jaki problem przypisać na takiej kartce dwie osoby do jednego zadania i posadzić ich do Pair Programmingu?”

      Rozumiem, że jako PO lub SM mam przydzielić człowieka do zadania? Nie bawmy się w Managerów bardzo proszę. Moja opinia jest jasna, przydzielanie człowieka do zadania skupia ludzi na wykonywaniu zadań a nie na celu sprintu.

      • Maciej,
        Łukaszowi chodziło chyba o to, by deweloperzy sami zaplanowali pracę w pair programming, a nie żeby ktoś spoza zespołu deweloperskiego przypisał do siebie ich członków.

  3. Uważam, że obi strony dyskusji mają rację, i nie mają jej zarazem 🙂 Otóż nie wszystko jest dla wszystkich, zatem w duchu inspekcji i adaptacji najprościej – w razie wątpliwości lub odmienności zdań w zespole – spróbować, a następnie wyciągnąć wnioski: kontynuować LUB zarzucić LUB zmodyfikować według potrzeb zespołu. No big deal 🙂


Odpowiedz na „KrzywyAnuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x