PO na Planowaniu Sprintu

Z jednej strony słyszymy pytania o to, jaki powinien być wkład Product Ownera na Planowaniu. Z drugiej strony sami wielokrotnie widzieliśmy sytuacje, w których zadawaliśmy sobie pytanie “Czy tak powinno być?” Co tak naprawdę robi PO na Planowaniu Sprintu?

 

PO na Planowaniu Sprintu

Lubimy pisać o Product Ownerze, choć nie poświęcamy może szczególnie dużo uwagi tej właśnie odpowiedzialności. Jak ważna jest to rola niech świadczy fakt, że działa on zarówno z Klientem (pracując nad wymaganiami), jak również z Zespołem Deweloperów (przekładając te wymagania na język dla nich zrozumiały, wyjaśniając dlaczego są ważne i do czego prowadzą).

Można więc powiedzieć, że Product Owner jest w centrum zamieszania. Nie ma się więc co dziwić, że powinien być obecny na każdym wydarzeniu, w tym na Planowaniu Sprintu. Jednak obecność Product Owera na tym wydarzeniu nie powinna zaburzyć sposobu jego przeprowadzenia czy celów, jakie powinniśmy osiągnąć. Skąd taki pomysł?

Antywzorców udziału PO na Planowaniu Sprintu jest naprawdę dużo i nie starczyłoby ani czasu, ani miejsca. Ponieważ nie ma to być tekst o narzekaniu, pozwólcie, że skupię się na najważniejszych. Na tych antywzorcach, które mają największy wpływ na Planowanie. Dzięki temu zostanie trochę miejsca na doradzenie, jak może być inaczej.

 

Antywzorce

Zastanawiając się na najważniejszymi antywzorcami, na pewno na pierwszy miejscy postawiłbym planowanie za Zespół. Mówiąc inaczej – decydowanie, co ma być wykonanie w planowanej właśnie iteracji. I nie mówię tutaj o priorytetyzacji. Mówię o decydowaniu przez PO o tym, “Co będzie robione?” Jest to o tyle niebezpieczne, że nie buduje współodpowiedzialności Zespołu za Cel Sprintu. Zabieramy Deweloperom poczucie, że “To my wybraliśmy, co będziemy robić.” Czasem nawet nie patrzymy na Capacity – ma być zrobione i tyle!

Czasem sprawy idę jeszcze dalej i PO zagłębia się również w kwestię “jak?”. Zamiast słuchać, co proponuje Zespół, zaufać, że ludzie posiadający kompetencje wiedzą jak najlepiej przełożyć wymagania na produkt, ustawia wszystkim prace, dyktując co ma być zrobione. Czasem Product Owner tworzy również zadania deweloperskie w Jira. “Przecież na wszystkim się znam.”

Kolejnym antywzorcem jest brak przygotowania Zespołu do planowania. Brak Refinementu, brak odpowiedniego opisania elementów Product Backlogu powodują, że planowanie, zamiast trwać 45 min będzie trwało faktycznie 8h (lub mniej dla Sprintów krótszych niż miesięczne). Nie będzie końca dyskusjom, dopytywaniu się “o co chodzi”.

 

Jak powinno być?

Product Owner podczas planowania, z wyjątkiem sytuacji opisanej w ostatnim rozdziale dzisiejszego wpisu, odpowiedzialny będzie za doradztwo i wyjaśnianie niejasności. Będzie doradzał w zakresie zakresu każdego z wymagań, znajdującego się w Backlogu.

Nie jest to wcale ograniczanie odpowiedzialności PO. Powyższe ma za zadanie oddanie Zespołom Deweloperów możliwości decydowania o planie na najbliższy Sprint. Daje też możliwość zdecydowania w jaki sposób praca ta zostanie wykonana.

Na czym więc jako Product Owner powinieneś się skupić? Przede wszystkim na przygotowaniu swojego Zespołu do tego wydarzenia. Jak mówi nowa wersja Scrum Guide, praca Product Ownera polega na zapewnieniu, aby członkowie Zespołu wiedzieli co planują. A jeśli podczas samego wydarzenia pojawią się pytania czy prośby o doprecyzowanie, rolą Product Ownera jest przekazanie informacji zwrotnej.

Reasumując, skupienie na przygotowaniu do planowania, uczestnictwo w roli osoby doskonale znającej wymagania i gotowej do udzielenia odpowiedzi na każde zadanie pytanie to odpowiedzialności Product Ownera. I na nich powinniśmy się skupić.

 

Zmiany w Scrum Guide 2020

Zmiany w Scrum Guide 2020 zawierają jedną ważną zmianę. Jeśli jesteś, drogi Product Ownerze, jednocześnie osobą wykonującą prace na rzecz przyrostu, będziesz uczestniczył w planowaniu na równi z Zespołem. Planować będziesz jedynie zakres tej pracy, którą to Ty masz wykonać. W pozostałej części, tam gdzie nie uczestniczysz w pracach deweloperskich, będziesz dla zespołu osoba odpowiedzialną za udzielanie odpowiedzi na padające pytania.

Dokładnie tak, jak napisałem powyżej.

Dodatkowo, w ramach pierwszej części Planowania Sprintu, razem z Zespołem Deweloperów PO określi Cel Sprintu, a więc tę najważniejszą rzecz, która będzie do osiągnięcia podczas kolejnych kilku tygodni. Na tym Twoja rola się kończy. Rozpoczyna się jednak na długo przed Planowaniem.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: