Wydarzenia Scrumowe: Planowanie (2)

Planowanie jest pierwszym wydarzeniem scrumowym, od którego zaczyna się każdy Sprint. Podobnie jak pozostałe 5 wydarzeń, daje możliwość praktykowania przejrzystości, inspekcji i adaptacji, które są filarami Scruma. Biorąc pod uwagę wiedzę uzyskaną w poprzednich Sprintach, Zespół planuje pracę, która przybliży ich do osiągnięcia Celu Produktu.

KILKA SŁÓW O PLANOWANIU

Scrum definiuje 5 wydarzeń: Sprint, Planowanie, Daily, Review i Retrospektywa. Planowanie jest wydarzeniem, które rozpoczyna każdy Sprint. Podczas jego trwania Zespół Scrumowy tworzy plan pracy, przeznaczony do realizacji w danym Sprincie.

Dla miesięcznego Sprintu Planowanie powinno trwać maksymalnie 8h. Dla krótszych Sprintów wydarzenie to trwa odpowiednio krócej.

W trakcie planowania należy rozważyć trzy tematy:

WHY, czyli dlaczego Sprint jest wartościowy

Po aktualizacji Scrum Guide [1] z 2020 roku, Planowanie Sprintu powinno zaczynać się od poszukiwania odpowiedzi na pytanie – dlaczego dany Sprint ma wartość? Product Owner przychodzi do Zespołu z propozycją wartości Produktu, którą przyniesie praca wykonana w danym Sprincie. Wspólna rozmowa na ten temat powinna przynieść ustalenia dotyczące oczekiwanego rezultatu (ang. outcome) [2].

Wynikiem tych rozważań powinien być Cel Sprintu, skupiony na planowanej wartości. Cel brzmiący np. „Ukończyć wszystkie PBI ze Sprint Backlogu” nie jest dobrym celem. Propozycję Celu Sprintu tworzy i przedstawia na Planowaniu Product Owner.

Cel Sprintu powinien powstać nie później niż na koniec planowania.

WHAT, czyli co może zostać Ukończone

Zespół Scrumowy ustala co należy zrealizować, by osiągnąć Cel Sprintu. Standardowo proces ten jest wyborem elementów Product Backlogu (ang. Product Backlog Item, PBI), które będą ukończone w ramach pracy koniecznej do dostarczenia ustalonej wartości dla Produktu.

Im lepiej przygotowane są elementy Product Backlogu, tym płynniej odbywa się Planowanie. Jeżeli praca nad Backlogiem odbywa się regularnie, we współpracy z Developerami, to Zespół zna założenia poszczególnych elementów. Członkowie Zespołu mają wtedy wyobrażenie dotyczące tego, co czeka na realizację, jeszcze zanim zacznie się Planowanie.

Jeżeli na Planowaniu pojawiają się elementy, które nie zostały omówione wcześniej na Refinemencie (lub są niejasne), to należy je uszczegółowić podczas spotkania. Należy dążyć do sytuacji, w której wszystkie PBI zaplanowane na Sprint są w pełni zrozumiałe.

Do dyskusji o zakresie pracy w Sprincie pomocna może być wiedza o dostępności poszczególnych osób z Zespołu (tzw. ang. capacity).

Należy wziąć pod uwagę również Definicję Ukończenia (ang. Definition of Done, DoD), która gwarantuje jakość Produktu. Z DoD na ogół wynika dodatkowa praca, którą należy uwzględniać podczas planowania [3]. Może być to code review, wymaganie testów automatycznych, testów back i white box, przygotowania dokumentacji etc. Im więcej punktów ma DoD tym bardziej pracochłonne będzie kończenie PBI.

HOW, czyli jak zostanie wykonana praca

Mając wybrane elementy Product Backlogu, Developerzy dla każdego z nich opracowują plan jego realizacji. Ustalają jak będą współpracować ze sobą, by zrealizować pracę. Częstą praktyką jest rozpisywanie każdego PBI na mniejsze zadania tzw. taski, uwzględniając w nich wymagania, które nakłada na Ukończony Inkrement Definicja Ukończenia.

Istotne jest jednak, że Scrum Guide pozostawia dowolność sposobu układania tego planu. Rozpisywanie na zadania nie jest konieczne. Ważne, by sposób opracowania planu pasował Developerom, a sam plan był dla wszystkich zrozumiały.

Sprint Backlog

Wyniki poszczególnych etapów Planowania (czyli Cel Sprintu), wybrane do realizacji elementy Product Backlogu oraz plan ich realizacji, tworzą Backlog Sprintu. Zarządzanie Sprint Backlogiem jest odpowiedzialnością Developerów.

Jaka jest rola Product Ownera W Planowaniu?

Pierwsza i najważniejsza kwestia – Product Owner musi być na Planowaniu. Każdy Sprint jest krokiem w stronę osiągnięcia Celu Produktu. Product Owner posiadający pasję, wizję, stojący na straży Celu Produktu oraz znający Roadmapę jest kluczowy, by wskazywać kierunek rozwoju i zarażać produktowym nastawieniem cały Zespół. Zatem jego dostępność jest niezwykle istotna, by mogły się odbywać merytoryczne i wartościowe rozmowy o wartości Sprintu [6].

Scrum Guide wprost określa odpowiedzialności PO w trakcie trwania tego wydarzenia. Nie ma zatem dobrego powodu, dla którego Product Owner może zrezygnować z pojawienia się na Planowaniu, jeżeli chcemy poprawnie implementować Scruma i uzyskać z niego możliwie najwięcej korzyści

Product Owner nadaje sens wykonywanej pracy

Każdy Sprint można traktować jak inwestycję [2]. Product Owner jest osobą, która powinna doskonale wiedzieć, dlaczego inwestujemy w wykonanie danego kawałka Produktu. Ma hipotezę dotyczącą spodziewanych rezultatów. Zwrotem z tak rozumianej inwestycji powinien być wzrost wartości Produktu.

Z dyskusji o tym w jaki sposób Sprint dostarczy wartość powinien wyłonić się jego Cel. Product Owner powinien przychodzić na planowane z przygotowaną propozycją Celu Sprintu. Jest to wstęp do zespołowego ustalenia obowiązującego Celu Sprintu i zakresu prac.

Przemyślany Cel Sprintu, skupiony na wartości dostarczanej przez Ukończony Przyrost na koniec Sprintu, jest istotnym elementem Sprint Backlogu. Nadaje on sens pracy i skupia działania Zespołu na dostarczanie wartości. Dobre uzasadnienie dla wykonywanych czynności przekłada się na wzrost motywacji.

O tym co można zyskać definiując Cele skupione na wartości pisałam tutaj.

Negocjacje zakresu Celu Sprintu

Tworząc Produkty pracujemy w złożonych i szybko zmieniających się środowiskach. Pracując w Scrumie, u którego podstaw stoi teoria empiryzmu, uznajemy, że nie jesteśmy w stanie przewidzieć przyszłości. Na każdym etapie pracy zwiększamy swoją wiedzę, która może ujawnić to co nieprzewidziane.

Czasami te niespodziewane czynniki powodują, że zaplanowana praca nie może zostać w całości zrealizowana. W takiej sytuacji Cel Sprintu daje możliwość negocjacji z Product Ownerem. Rezultatem tych negocjacji jest zmiana zakresu pracy w ramach ustalonego celu. Dzięki temu, mimo napotkanych trudności, dostarczenie ukończonego Inkrementu spełniającego ustalony Cel Sprintu jest możliwe. [5].

Weźmy za przykład sytuację, w której podczas tworzenia nowego systemu Zespół pracuje w Sprincie nad funkcjonalnością logowania. Cel Sprintu został ustalony jako „Użytkownik ma dostęp do portalu dzięki funkcji logowania”. Ustalony zakres prac składał się z możliwości stworzenia konta użytkownika, zalogowania się do systemu oraz funkcji resetu i odzyskania hasła.

W trakcie Sprintu niespodziewanie został wykryty błąd na środowisku produkcyjnym, na którego naprawę Zespół poświęcił dwa dni. Po tym wydarzeniu Zespół wiedział już, że nie będzie w stanie zrealizować całości pracy założonej na Planowaniu. Rozpoczyna negocjacje z Product Ownerem. Pozostawiając Cel bez zmian, zakres danego Sprintu zostaje zmniejszony o funkcję odzyskania hasła.

Przygotowany Product Backlog

Odpowiedzialnością Product Ownera jest przyjście na Planowanie z dobrze przygotowanym Product Backlogiem [6]. Jest on osobą gwarantującą, że uczestnicy wydarzenia są przygotowani do omówienia najważniejszych elementów Backlogu i wiedzą jak przekładają się one na Cel Produktu [1]. Taką gwarancję można uzyskać, jeżeli Product Owner cyklicznie spotyka się z Developerami na Refinementach i razem współpracują nad uszczegóławianiem Product Backlogu.

Rezultatem tych spotkań jest dobrze przygotowany Product Backlog. Dzięki nim rozwijamy też zespół Developerów, którzy znają założenia poszczególnych PBI i spodziewają się planu na dalszy rozwój Produktu. Backlog regularnie omawiany z Zespołem znacznie przyspiesza proces planowania.

O czym warto pamiętać

Cały Zespół ustala co zostanie zrealizowane w ramach pracy nad Celem Sprintu. Na ogół Cel jest bezpośrednio związany z Produktem. Product Owner powinien jednak dać Developerom przestrzeń na inne zadania poza rozwijaniem nowych funkcjonalności w Produkcie. Planowanie ilości pracy w oparciu o dane z poprzednich Sprintów (np. velocity) i zapełnianie Developerom czasu pracy „pod korek” nie jest dobrym pomysłem.

Warto planować walkę z długiem technicznym (ang. Technical debt), gdyż jego narastanie negatywnie wpływa na Total Cost of Ownership (TCO), za który odpowiada PO. Dług techniczny może z czasem zwiększać liczbę błędów w Produkcie, negatywnie wpływając na zadowolenie użytkowników. Będzie utrudniać utrzymanie Produktu i zwalniać tempo jego rozwoju. Wprowadzenie na pozór prostych zmian, może być wyzwaniem.

Nie zapominajmy również o wypracowanych akcjach z Retrospektywy. Retrospektywa umożliwia inspekcję procesów zespołowych i wypracowanie usprawnień. Jeżeli jednak nie będziemy tych usprawnień realizować, to stracimy istotną szansę na poprawę współpracy i procesów [3].

Zdarza się, że pewne PBI z poprzedniego Sprintu nie zostały ukończone. Zamiast mechanicznie przerzucać je do kolejnego Sprintu, warto się na chwilę zatrzymać i zastanowić, czy element ten jest nadal konieczny i przyniesie wartość.

Postawa Product Ownera

Product Owner jest równoprawnym członkiem Zespołu Scrumowego. Nie zarządza Developerami, a zatem nie układa planu działania i jego realizacji oraz nie dzieli zadań na poszczególne osoby [3]. Zamiast tego umożliwia samo-organizację. Na planowanie przychodzi nastawiony na współpracę. Łączy siły z Zespołem, by dojść do porozumienia jak najlepiej zaplanować Przyrost [4].

PODSUMOWANIE

Planowanie Sprintu to coś więcej niż spotkanie, na którym wybierane są elementy Product Backlogu do ukończenia w Sprincie. Dla Product Ownera jest to okazja by zarażać pozostałych członków Zespołu wizją Produktu i mówić o tym dlaczego tworzymy Produkt. Razem z Zespołem ustalają Cel Sprintu, który przyświeca ich dalszym działaniom w Sprincie, motywuje i nadaje sens ich pracy. Dzięki takiemu podejściu planowany Sprint może być krokiem w stronę osiągnięcia Celu Produktu i przynieść realną wartość.