Jeżeli na koniec Sprint Planningu jesteście w stanie odpowiedzieć na pytania: Dlaczego Co i Jak, to znaczy, że spotkanie zakończyło się sukcesem. Zanim do tego dojdzie pewnie chcielibyście wiedzieć jak zacząć. Jeden z prostszych sposobów zaplanowania Sprintu polega na tym, że Zespół bierze kolejny Element z góry Backlogu Produktu (tak zwany PBI, czyli Product Backlog Item) i:
- Omawia go z Product Ownerem i ekspertami, żeby zrozumieć, co jest do zrobienia. Jeżeli Porządkowanie Backlogu Produktu zostało wykonane porządnie, to Zespół dość dobrze wie co jest do zrobienia i często ten krok będzie albo formalnością, albo tylko odpowiedzią na kilka prostych pytań.
- Dzieli go na zadania techniczne. Oczywiście ma to sens, jeżeli Element jest duży i złożony. Jeżeli to godzina pracy jednej osoby to prawdopodobnie ten krok nie ma dużej wartości. Z drugiej strony chcielibyście wiedzieć, że przed wami zmiany w trzech różnych modułach backendu, poprawki na froncie i oczywiście testy, więc warto poświęcić chwilę, żeby omówić szczegóły.
- Szacuje wielkość zadań – łatwiej jest zaplanować Sprint, jeżeli wiemy co ile zajmie.
- Wspólnie decyduje czy plan Sprintu jest realny – czyli czy dadzą radę dostarczyć wszystkie wybrane elementy
- Jeżeli tak i uda się dostarczyć więcej to powtarza powyższe kroki dla kolejnego elementu z góry Backlogu Produktu.
- Jeżeli tak i więcej już się nie uda, to wygląda na to, że mamy realny plan Sprintu, czyli Backlog Sprintu.
- Jeżeli nie, to wzięli za dużo i muszą usunąć ostatni, najmniej wartościowy element z Backlogu Sprintu, albo zastanowić się, czy mogą dostarczyć tylko część, która dalej przyniesie wartość.
Gdy istnieje już Backlog Sprintu to wiele Zespołów ustali również Cel Sprintu – coś na czym będzie się mógł skupić. Na przykład „uruchomienie płatności”. Ułatwi to współpracę między członkami Zespołu i podejmowanie decyzji w trakcie Sprintu, jeżeli się okaże, że plan nie jest już realny.
Podsumowując, planowanie powinniście skończyć z informacją co chcecie osiągnąć (Cel Sprintu i wybrane Elementy Backlogu Produktu), oraz jak to chcecie zrobić (zadania i inne ustalenia).
Po planowaniu jesteście już gotowi do przeprowadzenia Sprintu.
Dobre praktyki planowania
Pamiętaj, na koniec Sprintu chcesz mieć w pełni funkcjonalny produkt. Planowane przez Was PBI mają wartość biznesową, no bo niby dlaczego inaczej mielibyśmy je robić. Dlatego Plan Sprintu nie będzie zawierać połowy Elementu – czyli na przykład samo kodowanie bez testowania.
Lepiej zaplanować mniej i dostarczyć więcej, bo na odwrót się zwykle nie udaje. Zespół, który może dostarczyć sześć elementów i zaplanuje sobie dziesięć z dużym prawdopodobieństwem dostarczy dwa. Reszta będzie „w trakcie”, czyli rozgrzebana, ograniczając możliwości podjęcia decyzji o zmianie priorytetów. Dlatego bezpieczniej jest zostawić bufor na różne nieprzewidziane sytuacje i ewentualnie dobrać dodatkowe PBI w trakcie trwania Sprintu.
Starajcie się nie przypisywać zadań do konkretnych osób w trakcie planowania. Zachowanie w stylu „moje, bo naplułem” pojawia się często u zespołów zaczynających pracę w Scrumie. Najczęściej powoduje to, że każdy zajmie się swoimi zadaniami, nie patrząc na to, czy razem osiągniemy cel. Jest duże ryzyko, że krytyczna praca nie zostanie wykonana, bo miał ją zrobić Kamil. A to za chwile będzie prowadziło do szukania winnych w postaci „nie udało nam się, bo Kamil zawalił”.
Elementy Backlogu Produktu powinny być nieduże. Od jednego do dwóch dni pracy całego Zespołu. Dobrą regułą jest nie przekraczanie przez jeden Element 1/2-1/3 całego Sprintu. W przeciwnym przypadku może się okazać, że zaplanowany element zajmie trochę więcej czasu i w tym Sprincie nie dostarczycie nic. A mieliście uzyskać przyrost produktu. Przegląd Sprintu raczej nie będzie okazją do świętowania.
Backlog Produktu musi być dobrze uporządkowany. Elementy na górze Backlogu mają być Gotowe (Ready) do implementacji. Nie oznacza to „zdefiniowane w 100%”, niektóre szczegóły mogą zostać ustalone w trakcie Sprintu. Jednak, gdy PO nie wie jakie są priorytety, ani co jest do zrobienia, to Planowanie Sprintu będzie długie i bolesne. Oczywiście na przygotowanie Backlogu macie czas w trakcie Porządkowania.
Plan Sprintu należy do Zespołu i to on jest odpowiedzialny za jego dostarczenie. Dlatego tylko członkowie Zespołu decydują jak dużo mogą zrobić w trakcie Sprintu. Ani Product Owner, ani żaden inny interesariusz nie ma prawa wymuszać zwiększenia zakresu Sprintu. Natomiast PO ma prawo ustawić kolejność Elementów w Backlogu. Scrum Master pomaga Zespołowi stworzyć realistyczny plan i chroni go przed zewnętrznymi naciskami.
Plan Sprintu – Odpowiedzialność Zespołu
Pierwsze Zespoły Scrumowe nazywały plan Sprintu commitmentem, czyli zobowiązaniem. Pomyśl o zespole sportowym wchodzącym na murawę. Czy zależy im na zwycięstwie? Czy dołożą wszelkich starań, żeby wygrać? Na pewno. To zachowanie opisuje angielskie słowo „commitment” pechowo tłumaczone w języku polskim jako zobowiązanie lub odpowiedzialność. Czy zawodnicy wygrają? Być może. To zależy od wielu czynników, nie koniecznie będących pod kontrolą zespołu. I tak należy traktować zobowiązanie Zespołu w Scrumie. Jednak w ciągu kolejnych lat to zobowiązanie zostało wypaczone i traktowane przez managerów jako „obiecaliście, że wygracie” albo „obiecaliście, że dostarczycie wszystkie zaplanowane Elementy z Backlogu Sprintu”. Niedostarczenie czegoś z przyczyn niezależnych od zespołu było (i często jest) traktowane jako porażka Zespołu, a nie informacja zwrotna na temat jego otoczenia. Dlatego od jakiegoś czasu mówimy, że plan Sprintu jest przewidywaniem (forecast). Ja wciąż chciałbym, żeby Zespół obiecał Product Ownerowi, że:
- Stworzyliśmy realny Plan Sprintu. Wierzymy, że możemy dostarczyć wszystkie Elementy – to znaczy, że każdy Element zostanie Skończony (zobacz DoD)
- Zrobimy wszystko co w naszej mocy, aby osiągnąć Cel Sprintu
- Damy Ci znać natychmiast, gdy pojawią się opóźnienia. W najgorszym wypadku wspólnie zadecydujemy o usunięciu z Backlogu Sprintu najmniej istotnego elementu.
- Damy Ci znać, jeżeli będziemy się poruszać szybciej, niż zakładaliśmy. Dzięki temu będziemy mogli wybrać następny Element z Backlogu Produktu i włączyć go do Backlogu Sprintu.
- Na koniec Sprintu będziemy mieli działający produkt.
