Planowanie Sprintu oparte na Velocity

Istnieją dwa podstawowe podejścia do planowania Sprintu:

1. Planowanie Sprintu oparte na Velocity (z uwzględnieniem średniego tempa pracy zespołu) oraz

2. Planowanie Sprintu oparte na Commitment (z uwzględnieniem tego, co zespół uważa, że jest w stanie osiągnąć w danym Sprincie).

Planowanie Sprintu oparte na Velocity

Tutaj skupiamy się na planowaniu Sprintu opartym na Velocity. Ilość pracy zaplanowanej na kolejny Sprint powinna być zbliżona do tej z poprzednich Sprintów. Zakłada to oczywiście, że skład zespołu pozostaje mniej więcej taki sam, że w kolejnych Sprintach realizowane są podobne zadania, że Sprinty mają zbliżoną długość itd. Na szczęście odchylenia od tych założeń są łatwe do wykrycia. Jeśli na przykład Sprint trwa dziewięć zamiast dziesięciu dni z powodu święta, zespół wie o tym już wcześniej.

Poszczególne kroki planowania Sprintu opartego na Velocity:

• Określenie średniej Velocity zespołu w poprzednich Sprintach.

• Wybranie odpowiedniej liczby Product Backlog Items na podstawie tej Velocity.

• Określenie poszczególnych zadań w ramach User Stories i ocena, czy stanowią właściwą ilość pracy.

• Ocena, czy te zadania wymagają podobnego nakładu pracy co zadania z poprzednich Sprintów.

Przyjrzyjmy się bliżej każdemu z tych kroków.

Krok 1: Wyznaczanie średniej Velocity zespołu

Pierwszym krokiem w planowaniu Sprintu opartym na Velocity jest ustalenie średniej Velocity zespołu. Niektóre zwinne zespoły kierują się wyłącznie Velocity z ostatniego Sprintu. Wiele z nich uważa, że to najlepszy wskaźnik tego, co można osiągnąć w kolejnym Sprincie. Nie jest to błędem, jednak może być pomocne spojrzenie nieco dalej wstecz – o ile takie dane są dostępne.

W tym celu analizuje się Velocity z ostatnich trzech do ośmiu Sprintów. Z doświadczenia wynika, że pozwala to całkiem dobrze przewidywać przyszłe Sprinty. Oczywiście nie należy przesadzać i obliczać średniej z ostatnich dziesięciu lat – nie mówiłoby to nic o aktualnej Velocity zespołu. Jeśli jednak dane z poprzednich Sprintów są dostępne, warto nie ograniczać się tylko do ostatniego.

Krok 2: Wybór Product Backlog Items

Na podstawie wyznaczonej średniej Velocity członkowie zespołu mogą wybrać Items na kolejny Sprint. Łącznie powinny one odpowiadać – przynajmniej w przybliżeniu – średniej Velocity.
W tym miejscu planowanie Sprintu oparte na Velocity jest w zasadzie zakończone i może zająć zaledwie kilka sekund – gdy tylko zespół dobierze Product Backlog Items zgodnie ze swoją średnią Velocity, może uznać zadanie za wykonane.

Krok 3: Określanie zadań (opcjonalnie)

Często jednak tak krótki czas na Sprint Planning nie wystarczy. Dlatego zespoły mogą dodać trzeci krok, w którym określają konkretne zadania do wykonania.
W tym celu członkowie zespołu omawiają każdy wybrany Product Backlog Item. Starają się ustalić, jakie czynności są potrzebne do jego ukończenia. Oczywiście nie da się przewidzieć wszystkiego, ale warto uwzględnić jak najwięcej.

Następnie zespół zastanawia się, czy wybrane Items i odpowiadające im zadania wypełnią cały Sprint. Na tej podstawie można jeszcze dodać lub usunąć kilka Items.

Niektóre zespoły kończą planowanie Sprintu na tym etapie, inne wykonują jeszcze jeden krok:

Krok 4: Szacowanie zadań (opcjonalnie)

Niektóre zespoły na końcu szacują, ile godzin zajmie im realizacja wybranych zadań. Dzięki temu mogą sprawdzić, czy zaplanowały odpowiednią ilość pracy.

Ten tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony na język polski.