Antywzorce w Scrumie – czego unikać? Część 2: Planowanie Sprintu

Jakiś czas temu na łamach agile247.pl pojawił się pierwszy z serii artykuł dotyczący anty-wzorców w Scrumie. Dzisiaj przyszła kolej, aby przeanalizować kolejne zdarzenie Scrumowe, a mianowicie Planowanie Sprintu (ang. Sprint Planning).

Poniżej znajdziecie subiektywne TOP 5 anty-wzorców dotyczących planowania Sprintu.

Sprint Planning: anty-wzorzec #1 (Refinement zamiast Planningu)

Po czym poznać? Członkowie Zespołu Deweloperskiego podczas Planowania Sprintu wykonują czynności typowe dla sesji pielęgnowania Product Backlogu (ang. refinement, wcześniejsza, wycofana nazwa: grooming), czyli tworzą elementy backlogu, uszczegóławiają je, dodają kryteria akceptacji, estymują czy też dzielą na mniejsze części.



Jakie są konsekwencje? Efektem tego anty-wzorca jest niezaplanowanie pracy na Sprint, ponieważ czas przeznaczony na planowanie zostanie skonsumowany na czynności związane z pielęgnacją Product Backlogu. Brak planu znacząco zwiększa ryzyko niepowodzenia Sprintu, co niejednokrotnie miałem okazję doświadczyć na własnej skórze. Oczywiście może się zdarzyć stytuacja, w której Product Owner przyniesie na Planowanie nowe zadanie dla zespołu wymagające omówienia, jednak co do zasady nie powinna być to reguła.

Co można zrobić inaczej? Zazwyczaj identyfikacja tego anty-wzorca to dopiero szczyt góry lodowej, związany najczęściej z brakiem cyklicznych sesji pielęgnacji Product Backlogu. Poniżej trzy proste podejścia, które zwyczajowo pomagają:

  • zaplanowanie regularnych sesji pielęgnacji Product Backlogu – fakt, że w podejściu zwinnym nie występuje długotrwała faza planowania, nie oznacza, że wymagania nie są omawiane. Dzieje się to w każdym Sprincie i zwyczajowo poświęca się na to ok. 10% czasu Sprintu (czyli 3,5h dla 1-tygodniowego Sprintu). Istnieje wiele podejść do wykorzystywania dostępnego czasu, np.
    • jednorazowa, długa sesja refinementu raz w tygodniu
    • codzienne omawianie jednego elementu z Product Backlogu np. po Codziennym Scrumie
    • dwie lub trzy sesje rozłożone w trakcie trwania Sprintu

Każde z wyżej wymienionych podjeść ma zarówno wady jak i zalety, co jednak wykracza poza zakres tego wpisu. Z drugiej strony, brzmi jak dobry temat na nowy artykuł 🙂

  • przeprowadzanie Przeglądu Sprintu zamiast sesji demo – częstym anty-wzorcem – o którym napiszę więcej w kolejnych odcinkach – jest traktowanie Przeglądu Sprintu wyłącznie jako okazji do przedstawienia Product Ownerowi oraz interesariuszom nowych funkcjonalności produktu. To, co powinno się zadziać oprócz “przeklikania” nowych rzeczy, to aktualizacja Product Backlogu na podstawie wiedzy, którą zdobędziemy od interesariuszy. Zazwyczaj podczas Przeglądu Sprintu jest czas, aby zastanowić się nad kolejnością elementów, będących najwyżej w Product Backlogu, dodać nowe elementy lub usunąć te, które są już niepotrzebne.
  • wprowadzenie DoR (ang. Definition of Ready) – jest to zwyczajowo prosta checklista, która określa, co to znaczy, że element Product Backlogu jest gotowy, aby wziąć go pod uwagę podczas Planowania Sprintu. Lista ta może być unikatowa dla każdego zespołu. Przykładowe, proste DoR mogłoby wyglądać następująco:
    • wymaganie zapisane jest w formie User Story
    • User Story spełnia zasadę INVEST
    • kryteria akceptacji są jasno określone
    • element jest wyestymowany
    • estymata jest mniejsza niż 13 punktów

Sprint Planning: anty-wzorzec #2 (Brak planu dostarczenia Sprintu)

Po czym poznać? Zespół przeprowadza Planowanie Sprintu, jednak efektem nie jest plan dostarczenia Sprintu. Warto zaznaczyć, że sama lista elementów Product Backlogu, nawet poszerzona o zadania techniczne, nie jest wystarczającym planem.

Jakie są konsekwencje? Po Planowaniu Sprintu zespół jako całość nie ma obrazu tego, co wydarzy się w ciągu najbliższych dni. Wie, że są pewne zadania do wykonania, jednak brakuje zrozumienia, w jaki sposób elementu Product Backlogu zostaną zamienione na działające oprogramowanie.

Co można zrobić inaczej?

  • przygotować faktyczny plan -przyjmuje on najczęściej postać diagramu, rysunku lub po prostu listy kroków, które muszą zostać wykonane, aby osiągnąć Cel Sprintu. Warto rozważyć takie obszary jak:
    • kolejność wykonywania zadań
    • osadzenie w czasie
    • ważność wykonywanych kroków
    • zależności zewnętrzne (np. z innymi zespołami/dostawcami)
    • zależności wewnętrzne (np. zależność frontendu aplikacji z backendem)
    • wszelkie niejasności
    • ryzyka
  • spędzić więcej czasu na drugiej części planowania – pierwsza część planowania odpowiada na pytanie “co zostanie zrealizowane”, druga część na pytanie “jak zostanie zrealizowane”. Przy dobrze przygotowanym Product Backlogu, pierwsza część planowania trwa krótko (max. 30 minut), więc dla 1-tygodniowego Sprintu pozostaje 1h 30 minut na zaplanowanie, jak zostanie wykonana praca.
  • poprosić osobę z Zespołu Deweloperskiego o opowiedzenie własnymi słowami, jak rozumie plan Sprintu – ta prosta technika daje szybką odpowiedź, czy plan jest zrozumiały dla Zespołu Deweloperskiego. Gdy plan jest niedostatecznie szczegółowy, najprawdopodobniej ktoś z zespołu odezwie się w z wypowiedzią w stylu “chwila chwila… zanim zaktualizujemy bazę danych, muszę uruchomić kilka skryptów”. Jest to okazja, aby uszczegółowić niejasny element (lub elementy) planu.

Sprint Planning: anty-wzorzec #3 (Brak Celu Sprintu)

Po czym poznać? Zespół wybiera elementy Product Backlogu, które prognozuje dostarczyć w nadchodzącym Sprincie, jednak nie powstaje Cel Sprintu, który jest wskazówką dla Zespołu Deweloperskiego, co powinno być efektem końcowym iteracji.

Jakie są konsekwencje? Zespół nie ma jasnej informacji, dlaczego realizuje wybrany przyrost. Komunikowanie powodów, dla których realizujemy konkretne zadania, jest istotne dla zrozumienia kontekstu biznesowego realizowanego produktu. Dodatkowo, brak wspólnego celu dla zespołu może spowodować, że zamiast współpracować nad realizacją Celu Sprintu, członkowie zespołu będą pracować “na własną rękę” nad pojedynczymi zadaniami, co może doprowadzić do niespójności na koniec Sprintu (np. “myślałem, że w tym zadaniu inaczej przygotujesz API”). Zespół potrzebuje pewnego spoiwa, które zapewni, że będą poruszać się w tym samym kierunku.

Co można zrobić inaczej?

  • zacząć Planowanie Sprintu od dyskusji na temat Celu Sprintu – taka dyskusja pomaga dotrzeć do potrzeb Product Ownera, które nie zawsze są wyrażone w czytelny sposób w postaci elementów Product Backlogu. Pomocne mogą być pytania, skierowane do Product Ownera:
    • “co chciałbyś otrzymać na koniec Sprintu?”
    • “jaki cel biznesowy kryje się za elementami, które zaproponowałeś na bieżący Sprint?”

Sprint Planning: anty-wzorzec #4 (Planowanie na wyczucie)

Po czym poznać? Zespół podczas Planowania Sprintu nie bierze pod uwagę metryk oraz danych historycznych. Decyzja dotycząca ilości oraz doboru elementów, które zespół prognozuje dostarczyć, podejmowana jest “na wyczucie”. Niekorzystanie z dostępnych danych najczęściej wynika z faktu, że nie są kolekcjonowane.

Jakie są konsekwencje? Zwiększone ryzyko związane z realizacją bieżącego Sprintu. Cała wiedza zdobyta przez Zespół Deweloperski dotycząca procesu nie jest wykorzystywana.

Co można zrobić inaczej? Poniżej kilka przykładów wykorzystania metryk oraz danych historycznych:

  • historyczna prędkość zespołu (ang. velocity) – prędkość zespołu informuje, jak dużo Zespół Deweloperski jest w stanie dostarczyć w trakcie pojedynczego Sprintu. Podczas Planowania Sprintu przydatne jest spojrzenie na:
    • ostatnią prędkość zespołu (tzw. “yesterday weather”), oraz
    • średnią prędkość z kilku ostatnich Sprintów
  • przewidywalność zespołu – jest to stosunek tego, co dostarczyliśmy w Sprincie, w stosunku do tego, co planowaliśmy dostarczyć. Przykładowo, jeśli na koniec Planowania Sprintu Zespół Deweloperski prognozuje, że dostarczy 100 Story Pointów, a na koniec Sprintu dostarcza 80 Story Pointów, to przewidywalność tego zespołu wynosi 80%. Warto spojrzeć na historyczne rezultaty, aby ocenić, czy częściej mamy problem z niedoszacowaniem, czy też z przeszacowaniem zadań.
  • trafność estymat – technika szczególnie skuteczna jeśli chodzi o identyfikację ryzyk. Każde zadanie, które zrealizowaliśmy w Sprincie ponownie estymujemy, kiedy zostanie już zrealizowane. Pozwala to stworzyć tabelkę, która z czasem powie nam, jak trafnie estymujemy poszczególne rozmiary zadań, np. 1 Stor Point = 98%, 2 Story Pointy = 95%, 3 Story Pointy = 87% itd. Im wyższa estymata (bardziej złożone zadanie), tym mniejsza szansa na prawidłowe określenie estymaty. Podejście to pozwala określić liczbę Story Pointów, których przekroczenie powoduje, że zespół nie bierze takiego zadania do Sprintu z powodu zbyt dużego ryzyka, że zadanie okaże się większe niż się spodziewaliśmy.
  • średnia liczba zrealizowanych elementów per Sprint – jeżeli elementy, które realizujemy są podobnej wielkości, możemy zliczać przepustowość naszego procesu (np. realizujemy 15 elementów z Product Backlogu per Sprint). Jest to zaawansowane podejście, wymaga bowiem dużej wprawy w przygotowywaniu naprawdę małych elementów Product Backlogu, jednak w efekcie daje duże możliwości. Dla zainteresowanych tego rodzaju podejściem odsyłam do artykułu dotyczącego ruchu #noestmates.

Sprint Planning: anty-wzorzec #5 (Planują wyłącznie programiści)

Po czym poznać? Wyłącznie programiści z Zespołu Deweloperskiego biorą aktywny udział w Planowaniu Sprintu. Reszta zespołu (testerzy, UX, analitycy, devops, …) biernie uczestniczy w spotkaniu.

Jakie są konsekwencje? Zespół planuje pracę tylko przez pryzmat prac programistycznych. Pozostałe obszary produktu – konieczne, aby dostarczyć zbywalny kawałek oprogramowania – pozostają nieomówione. Łatwo wpaść w pułapkę niedoszacowania ryzyk, np. gdy deweloperzy oceniają element Product Backlogu jako prosty programistycznie, nie zdając sobie sprawy, ze zmiana może być bardzo wymagająca jeśli chodzi o testy. Może to też doprowadzić do gorącego okresu pod koniec Sprintu, gdy po luźnym z testerskiego punktu widzenia początku Sprintu, nagle duża część elementów realizowanych w Sprincie będzie wymagała przeprowadzenia testów.

Co można zrobić inaczej? Poniżej dwa proste podejścia, które pozwolą zaangażować cały zespół:

  • praca w małych, wymieszanych grupach – na początku planowania dzielimy Zespół Deweloperski na małe 2-3 osobowe grupy, składające się z jak największej liczby kompetencji (np. programista + tester + UX). Następnie zespół pracuje w grupach, co pozwala na spojrzenie na zadanie z różnych perspektyw. Pełny opis tej techniki można znaleźć tutaj.
  • zmoderować spotkanie – rozwiązanie to brzmi banalnie, jednak czasem właśnie dobra moderacja jest tym, czego brakuje. Czujny moderator wyłapie sytuacje, w której wyłącznie programiści dyskutują i odpowiednim pytaniem (“A jak to zadanie wygląda z perspektywy QA?”) lub obserwacją (“Widzę, że tylko programiści biorą udział w dyskusji”) aktywuje pozostałe role.

Podsumowanie

Planowanie Sprintu to jedno z najważniejszych zdarzeń w Scrumie. Potencjał tego wydarzenia jest ogromny, jeśli tylko wiemy, jak z niego skorzystać. Słabo zaplanowany Sprint z reguły prowadzi do kiepskiego Sprint Review oraz owocuje grymasami niezadowolenia interesariuszy. Tego chyba chcemy uniknąć, prawda?

Standardowo zapraszam do dyskusji – jakie anty-wzorce są największym wrogiem Planowania Sprintu z Waszej perspektywy? Koniecznie dajcie znać w komentarzach.

Chcesz przeczytać więcej?

Powyższy artykuł to mały wycinek mojej książki “Labirynty Scruma”, której premierę planuję w okolicy połowy 2017 roku. Opisuję w niej sprawdzone, praktyczne sposoby na najczęstsze pułapki w Scrumie. Zapisz się na mój newsletter – dla subskrybentów planuję przedpremierowy fragment książki oraz dodatkowe materiały.

Posłuchaj też 47 odcinka podcastu Porządny Agile, którego tematem jest Definition of Ready.

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