Dwie części Sprint Planning

Sprint Planning to jedyne wydarzenie scrumowe, które jest podzielone na dwie części. Zaskakujące, jak wiele osób o tym zapomina…

 

Sprint Planning w pigułce

Planowanie Sprintu to spotkanie, które jak sama nazwa wskazuje, służy zaplanowaniu prac prognozowanych do realizacji w ciągu bieżącego Sprintu. “Bieżącego”, bo między Sprint Retrospective z poprzedniej iteracji, a planowaniem z obecnej nie ma czasu na odpoczynek ani na inne prace. “Prognozowanych”, bo nie jest to zobowiązanie zespołu, a jedynie szacunki oparte o dane historyczne i doświadczenie.

Timebox, czyli maksymalny czas trwania dla tego wydarzenia, to osiem godzin. Czy to nie za dużo? Osiem godzin dotyczy miesięcznych iteracji, a jak wiemy przeciętny Sprint jest krótszy o połowę. To już daje nam “tylko” (lub “aż”) cztery godziny na zaplanowanie najbliższych dwóch tygodni.

Tak jak Sprint Planning podzielony jest na dwie części, tak i są dwa produkty tego spotkania: Sprint Backlog i Sprint Goal. Warto pamiętać o obu tych artefaktach i sprawdzić czy faktycznie są kompletne na końcu Planowania Sprintu. Chociaż tak naprawdę Cel Sprintu powstanie już w trakcie pierwszej części tego wydarzenia.

 

Planowanie Sprintu, część pierwsza: “Co?”

“What can be delivered in the Increment resulting from the upcoming Sprint?” – Scrum Guide

W pierwszym kroku Zespół Deweloperski musi zdecydować, ile pracy jest w stanie wykonać w ciągu najbliższej iteracji. Idąc od szczytu Backlogu omawia z Product Ownerem kolejne wymagania, w szczególności to, jak się one mają do Celu Sprintu i czy jeszcze się zmieszczą w przewidzianym czasie.

To nie jest jednak miejsce na Product Backlog Refinement! Jeżeli jakieś wymaganie nie jest zrozumiałe przez absolutnie wszystkich, powinno zostać odłożone z powrotem do Backlogu Produktu. Na planowaniu ma nic gorszego, niż zagłębianie się w analizę User Stories, o którym prawie nic nie wiemy. Nie tylko stracimy czas, ale i skupienie uczestników spotkania.

W przypadku nacisków ze strony PO, to członkowie zespołu lub Scrum Master powinni jasno i wyraźnie powiedzieć, że zaplanowanie prac wymagania w którym jest zbyt wiele niewiadomych może zagrozić zrealizowaniu wszystkich prac. Skoro nie wiemy co robimy, to i nie możemy wiedzieć ile nam to zajmie.

Warto mieć pod ręką Product Backlog, ostatni Inkrement oraz historyczne i spodziewane Velocity zespołu. Wszystko to po to, żeby ułatwić członkom zespołu, którzy będą te prace wykonywać, decyzję o tym “ile wziąć na Sprint”.

Bo to Zespół Deweloperski decyduje o tym, co finalnie trafi do Sprint Backlogu i nikt nie może wpłynąć na jego decyzję. Jednak należy też pamiętać, że to cały Scrum Team, wraz z Product Ownerem i Scrum Masterem, tworzą Sprint Goal. O zdefiniowanym celu powinniśmy pamiętać w drugiej drugiej i w trakcie całego Sprintu.

 

Planowanie Sprintu, część druga: “Jak?”

“How will the work needed to deliver the Increment be achieved?” – Scrum Guide

Wydawałoby się, że po ustaleniu “co robimy”, wszystko jest już jasne i można zabierać się do pracy. Nie tak szybko! Zostało jeszcze potwierdzenie, że wszystko co zaplanowaliśmy ma szansę zmieścić się w Sprincie i upewnienie się, że wiemy jak zabrać się do każdego zadania. “Zabrać”, czyli niekoniecznie “zrealizować od A do Z”.

Tym właśnie zajmujemy się w drugim kroku. Development Team zwykle rozpisuje wybrane w pierwszej części wymagania na mniej lub bardziej szczegółowe zadania. Dla niektórych będziemy rozpisywać szczegółowe “taski“, a dla innych wystarczy nam spisanie ogólnego planu.

Jak bardzo powinniśmy wchodzić w detale? Nic nikomu do tego! Zespół Deweloperski jest samoorganizujący się i jako taki sam decyduje, jaki poziom szczegółowości jest wystarczający. Zazwyczaj praca na pierwszych kilka dni rozpisywana jest w taki sposób, żeby można było bez problemu podzielić się zadaniami.

Jak mówi Scrum Guide, na koniec planowania Zespół Deweloperski powinien być w stanie opowiedzieć Product Ownerowi, w jaki sposób mają zamiar osiągnąć Cel Sprintu i zbudować Inkrement. Nie znaczy to, że mają od razu rzucać nazwami klas i mówić w którym pliku i która linia ulegnie zmianie.

Jednak niedopuszczalną sytuacją jest, gdy zespół odpowiada, że “jakoś da radę”. Musimy wiedzieć, jak w ogóle zabrać się do realizacji każdego wymagania. Jeżeli tego nie wiemy, to nie powinno ono w ogóle znaleźć się w Sprint Backlogu. A tak naprawdę, nie powinno w ogóle trafić na Sprint Planning.

Nie o taki Sprint Planning nam chodzi...

Niby i w ten sposób można planować “sprint”, ale nie o to chodzi w Planowaniu Sprintu.

 

Sprint Planning w praktyce

W praktyce Sprint Planning jest często trochę mniej uporządkowany, niż by wynikałoby to z powyższego opisu. Owszem, zwykle najpierw ustalamy “co”, potem próbujemy opisać “jak” i utworzyć zadania (lub podzadania), które trafią do Sprint Backlogu. Na koniec jednak może okazać się, że jest ich za dużo lub za mało.

W takim przypadku wracamy do punktu pierwszego i Zespół Deweloperski negocjuje z Product Ownerem zakres zaplanowanych prac. Pamiętajmy, że Sprint Backlog to oszacowanie, a nie zobowiązanie. Dobrze by było, gdyby wszystkie elementy z tej listy zostały ukończone, ale tak naprawdę najbardziej zależy nam na osiągnięciu Celu Sprintu. Dlatego też tak ważna jest rozmowa na linii Development Team – PO.

Przyda się ona także w kwestii wyboru wymagań z Backlogu Produktu. W teorii, jest to lista uporządkowana i powinniśmy wybierać elementy od góry, aż do momentu w którym uznamy, że więcej nie damy rady zrealizować. W praktyce jednak czasami warto przeskoczyć kilka wymagań i zrealizować jakieś potencjalnie mniej istotne, żeby ułatwić późniejsze prace lub zadbać o jakość. Takie decyzje nie są niczym szczególnym, ale zawsze odbywają się w porozumieniu z Product Ownerem.

To pokazuje też, że nie da się uniknąć dyskusji o kolejnych iteracjach, zwłaszcza jeżeli odkładamy jakieś wymaganie “na później”. Pamiętajmy jednak, że planujemy tylko i wyłącznie najbliższy Sprint. Często pojawia się pytanie “Dlaczego nie dzielimy backlogu na Sprinty?“. Odpowiedź jest prosta: zbiór wymagań żyje i zarówno jego zawartość, jak i kolejność zmienia się po każdym ukończonym Sprincie.

Może i nasz plan “na kolejny Sprint” jeszcze byłby ok, ale już wybieganie trzy-cztery iteracje do przodu po prostu się nie sprawdza. Przez taki czas zbyt wiele się zmieni, nasz plan wyląduje w koszu, a czas poświęcony na jego przygotowanie będzie stracony.

 

Szczegółowe Planowanie Sprintu

Niektóre zespoły rozpisują wszystkie wymagania na szczegółowe zadania już na spotkaniu Sprint Planning. Zwykle szczegóły realizacji zadań odkrywamy dopiero w trakcie prac realizowanych w Sprincie. W Scrumie, przed rozpoczęciem Sprintu, nie mamy przecież gotowej i kompletnej analizy. Wiemy “jak” będziemy podchodzić do każdego wymagania, ale szczegóły poznamy dopiero wraz z postępem prac.

Jeżeli mamy szczegółową wiedzę na temat sposobu realizacji zadań, a także czas i miejsce, to możemy zaryzykować zwinny eksperyment. Rozpiszmy na Planowaniu Sprintu wszystkie zadania, jakie naszym zdaniem będą składały się na realizację każdego z wymagań. Rezultat tego eksperymentu powie nam, czy warto określać takie szczegóły już na planowaniu. Nie da się ukryć, że aby to osiągnąć, musimy mieć pewność, że sposób realizacji wymagań się nie zmieni.

W podobny, empiryczny sposób próba zrealizowania uzgodnionego zakresu powie nam o tym, czy zaplanowaliśmy za dużo czy za mało. Oczywiście może nam w tym pomóc Velocity, trzeba jednak pamiętać, że szacunki wielkości zadań wyrażone w postaci np. Story Points nie są precyzyjne. Liczy się przede wszystkim doświadczenie.

 

Skalowanie Sprint Planning

Scrum działa idealnie dla jednego zespołu, a bardzo dobrze – dla dwóch. Później zaczynają się problemy. W przypadku spotkania Sprint Planning z pomocą przychodzi sam Scrum Guide i podział planowania na dwie części.

Jeżeli kilka Zespołów Scrumowych pracuje na jednym Backlogu Produktu, to sprawa jest bardzo prosta. Pierwszą część spotkania czyli “co” realizujemy wspólnie, dzieląc wymagania między poszczególne zespoły, aż wszystkie powiedzą “dość”. Absolutnie kluczowy okaże się tutaj dobrze przygotowany backlog. Bez niego nie ma żadnych szans na udane spotkanie.

Na drugą część Planowania Sprintu zespoły zwykle rozchodzą się i realizują je jak na samoorganizujące się jednostki przystało – osobno. Tutaj co prawda problemem może być dostępność Product Ownera, który jest tylko jeden na kilka zespołów, ale zwykle nie przeszkadza to aż tak bardzo. Istnieją też sposoby, żeby tę dostępność zwiększyć (patrz np. Proxy Product Owner).

Jeszcze więcej komplikacji pojawia się w dużych organizacjach, gdzie mamy do czynienia np. z Release Planningiem. To jednak jest tematyka, którą poruszamy w innych tekstach na naszym zwinnym blogu, oraz oczywiście na szkoleniach Scrum.

 

W przypadku innych konfiguracji, wielu Product Ownerów, kilku backlogów, masy zależności i rosnącej wielkości projektu, sprawy się nieco komplikują. Jeżeli jesteś tym zainteresowany lub zastanawiasz się jak skalować pozostałe wydarzenia scrumowe, role i jak uniknąć pułapek związanych ze zwiększającą się liczbą zespołów, skorzystaj z naszych warsztatów Skalowanie Scrum.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: