Opublikowano: 26.10.2018

Jak może wyglądać planowanie Sprintu?

Jak może wyglądać planowanie Sprintu?

Jeżeli na koniec planowania jesteście w stanie odpowiedzieć na pytania 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 Element z góry Rejestru 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 Rejestru 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 sensu. Z drugiej strony warto wiedzieć, że przed wami zmiany w trzech różnych modułach backendu, poprawki na froncie i oczywiście testy.
  • Szacuje wielkość zadań – łatwiej jest zaplanować Sprint, jeżeli wiemy co ile zajmie. Więcej na ten temat znajdziesz w rozdziale Szacowanie i Planowanie
  • 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 powtarzamy powyższe kroki dla kolejnego elementu z góry Rejestru Produktu.
    • Jeżeli tak i więcej już się nie uda, to wygląda na to, że mamy realny plan Sprintu, czyli Rejest Sprintu (Sprint Backlog).
    • Jeżeli nie, to wzięliśmy za dużo i musimy usunąć ostatni, najmniej wartościowy element z Rejestru Sprintu, albo zastanowić się, czy możemy dostarczyć tylko część.

Gdy mamy już Rejestr 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 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 Rejestru Produktu), oraz jak to chcecie zrobić (zadania i inne ustalenia).

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 proprytetó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 Rejestru 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.

Rejestr Produktu musi dobrze uporządkowany. Elementy na górze Rejestru mają być Gotowe 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 Rejestru 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 Rejestrze. Scrum Master pomaga Zespołowi stworzyć realistyczny plan i chroni go przed zewnętrznymi naciskami.

Plan Sprintu – Odpowiedzialność Zespołu

Pierwsze Zespołu Scrumowe nazywały plan Sprintu commitmentem, czyli zobowiązaniem. Pomyśl o zespole sportowym wchodzącym na murawę. Czy są zależy im na zwycięstwie? Czy dołożą wszelkich starań , żeby wygrać? Na pewno. To zachowanie opisuje angileskie 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 Rejestru 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 Rejestru 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 Rejestru Produktu i włączyć go do Rejestru Sprintu.
  • Na koniec Sprintu będziemy mieli działający produkt.
Tomasz Wykowski

Tomasz Wykowski

Międzynarodowy gawędziarz i jedyny polski trener Scrum Alliance. Ciągle poszukuje nowych rozwiązań.

Podobne

Komentarze (0)

Brak komentarzy, dodaj pierwszy!

Dodaj komentarz