Najczęstszym zaobserwowanym przeze mnie sposobem na przeprowadzenie drugiej części Planowania Sprintu jest następujący scenariusz: Scrum Master wspomaga Zespół Deweloperski, który pracując jako jedna całość, przygotowuje plan wykonania Sprintu.
Po kilkudziesięciu planningach przeprowadzonych w ten sposób, można zaproponować alternatywne podejście planowania, aby spotkanie to nadal było przyjemnym sposobem na przygotowanie się do Sprintu, a nie nudnym i powtarzalnym obowiązkiem.
Jaki jest pomysł na drugą część Planowania Sprintu?
Planowanie Sprintu w grupach.
Co potrzebujemy?
- wydrukowane lub rozpisane na kartkach Historie Użytkownika
- bloczek kartek samoprzylepnych
- kilka kartek A4
- kilka pisaków/długopisów
- pomieszczenie ze stołami
Jak przebiega Planowanie?
- Dzielimy Zespół na dwie grupy
- Zadania wstępnie przyjęte na Sprint dzielimy równo pomiędzy nowo powstałe grupy
- Każda grupa opracowuje plan wykonania Sprintu dla otrzymanych Historii Użytkownika, wynikiem czego powinien być ogólny zarys najbliższej pracy do wykonania oraz oszacowane zadania techniczne
- Po upłynięciu określonego wcześniej czasu, grupy kończą pracę i pierwsza z grup przedstawia efekty swojej pracy
- Druga grupa zadaje pytania oraz dyskutuje zaproponowane rozwiązanie
- Następuje zmiana grup – ta, która dotychczas słuchała, przedstawia swoje rozwiązanie, natomiast ta, która prezentowała efekty swojej pracy, zadaje pytania oraz dyskutuje
- Grupy łączą efekty swojej pracy w jedną całość i upewniają się – już jako połączony ponownie Zespół – czy na skutek rozbicia na dwie grupy, nie zostało utracone globalne spojrzenie na problem
Na co zwrócić uwagę?
- grupy powinny być w miarę porównywalne pod względem umiejętności
- czas przeznaczony na poszczególne etapy trzeba sumiennie mierzyć, aby płynnie przejść wszystkie fazy
Photo by You X Ventures on Unsplash
2 odpowiedzi
Takie rozwiązanie niestety średnio się sprawdzi dla mniejszych zespołów scrumowych, owszem może być to jakieś uatrakcyjnienie sprint planningu, ale wypracowanie dwóch różniących się od siebie rozwiązań, a następnie wypracowywanie jednego wspólnego wariantu moż okazać się bardzo czasochłonne. Zabrakło mi także zdecydowanie jakiejś próby szacowania historyjek, zadań, aby mierzyć velocity zespołu.
Zapraszam do odwiedzenia mojego bloga o metodyce scrum i ogólnie o zarządzaniu projektami. http://jestempm.pl
@Jarek – dzięki za komentarz.
Nie chodzi o dwa różne rozwiązania dla tego samego zadania. Każda grupa bierze swoją część zadań (no. po 3 zadania), przygotowuje je i na sam koniec łączą wyniki swojej pracy w jedno rozwiązanie. Używałem tej techniki w zespole 5 osobowym i efekty były zadowalające (zwyczajowo po użyciu konkretnej techniki proszę zespół na koniec o ocenę, np. od 1 do 5, gdzie 1 to „niedostatecznie”, 5 – „bardzo dobrze”).
Jeśli chodzi o szacowanie – założyłeś, że nie wystąpiło, natomiast wystąpiło, tylko *zanim* weszliśmy na Planowanie Sprintu – mianowicie na Refinemencie. Staram się nie wchodzić bez estymat na Planowanie, oceniam to to bowiem jako ryzykowne – co jeśli okaże się, że zadania są zbyt duże/niejasne/nie gotowe?
Natomiast generalnie, to blisko mi do mądrości Alistaira Cockburna – „każda technika działa i nie działa jednocześnie” :) Coś, co działa w moim zespole, może nie zadziałać w Twoim i odwrotnie. Wynika to ze złożoności środowiska w którym na co dzień pracujemy, gdzie bywa że nie działają ani najlepsze, ani nawet dobre praktyki. Chętnych na pogłębienie tematu dlaczego tak to właśnie jest, odsyłam do modelu Cynefin (http://jacekwieczorek.agony.webd.pl/model-cynefin-w-scrumie/) oraz pierwszej części książki „Management 3.0” Jurgen’a Appelo (http://jacekwieczorek.agony.webd.pl/management-3-0-leading-agile-developers-developing-agile-leaders-jurgen-appelo/).