Zaangażowane Planowanie Sprintu

Istnieją dwa podstawowe sposoby planowania Sprintu:

1) Planowanie Sprintu oparte na Velocity
(z uwzględnieniem średniego tempa pracy zespołu), i
2) Planowanie Sprintu oparte na Commitment
(z uwzględnieniem tego, co zespół wierzy, że jest w stanie osiągnąć w Sprincie)

Planowanie Sprintu oparte na Velocity już wyjaśniłem, więc skupmy się tutaj na Planowaniu Sprintu opartym na Commitment:

Spotkania planowania Sprintu oparte na Commitment angażują Product Ownera, Scrum Mastera i cały zespół deweloperski. Product Owner przedstawia przegląd elementów Product Backlogu o najwyższym priorytecie i wyjaśnia je zespołowi.

Wybieranie elementu

Następnie członkowie zespołu wybierają element na kolejny Sprint. W większości przypadków pokrywa się to z elementem, któremu Product Owner nadał najwyższy priorytet. Może się jednak zdarzyć, że element Product Ownera zawiera jeszcze zbyt wiele nierozwiązanych kwestii.

W idealnym przypadku zespół powinien jednak być w stanie włączyć ten element do Sprintu i wyjaśnić otwarte kwestie wystarczająco wcześnie, aby móc go mimo wszystko ukończyć. Jeśli jednak jest zbyt wiele, zbyt poważnych lub zbyt czasochłonnych kwestii do rozwiązania, element wybrany przez Product Ownera powinien na razie zostać pominięty.

Zadania i godziny

Po wybraniu elementu członkowie zespołu omawiają związaną z nim pracę i ustalają zadania (Tasks) niezbędne do dostarczenia elementu Product Backlogu. Podczas tego lub bezpośrednio po tym zespół szacuje, ile czasu (godzin) zajmą im poszczególne Tasks.

Nie oczekuj jednak, że zespół będzie szacował każde zadanie. Jest to nie tylko niemożliwe, ale i niepotrzebne.

Członkowie zespołu powinni szacować tylko tyle Tasks, ile potrzeba, aby poczuli, że wszystko zostało wystarczająco przemyślane. Bo to jest właściwy cel takiego spotkania. Ustalanie Tasks i liczby godzin jest sprawą drugorzędną.

Pytanie o Commitments

Gdy tylko członkowie zespołu ustalili Tasks i mają przybliżone pojęcie, ile czasu zajmują określone elementy Backlogu, powinni zadać sobie pytanie: „Czy możemy podjąć Commitment?"

Uważam za ważne, żeby zespół sam sobie to pytanie zadał, a nie żeby Scrum Master pytał: „Czy możecie podjąć Commitment?" Ponieważ w ten sposób zobowiązują się wobec siebie nawzajem, a nie wobec Scrum Mastera.

Nie wiem jak u Was, ale moje pierwsze lata w pracy (w czasach przed Scrumem) były naznaczone nierealizowalnymi zobowiązaniami wobec przełożonych, którzy pytali „Czy dacie radę?", ale tak naprawdę mieli na myśli „Zadbajcie o to, żeby dać radę!"

Mimo że Scrum Master jest nazywany „Masterem", nie jest przełożonym zespołu i nie powinien takiego wrażenia sprawiać. Lepiej nie być postrzeganym jako szef, który domaga się wypełnienia wszystkich Commitmentów.

Zamiast tego należy skłonić zespół do samodzielnego zadania pytania: „Czy możemy podjąć Commitment?" Bo Commitment jest dużo silniejszy, gdy zespół zobowiązuje się wobec siebie samego.

Poza tym jest oczywiste, że na pytanie zespołu „Czy możemy podjąć Commitment?" mogą być tylko dwie odpowiedzi: „Tak, możemy" lub „Nie, nie możemy". Gdy natomiast Scrum Master pyta „Czy możecie podjąć Commitment?", niektórzy członkowie zespołu odpowiedzą „my", a inni „ja".

Scrum wymaga Commitmentu całego zespołu: „Jeśli będziesz potrzebować pomocy, pomogę ci i wiem, że ty zrobiłbyś to samo dla mnie." a nie „To są moje zadania, a tamte twoje."

Powtarzanie procesu dla kolejnych Stories

Jeśli zespół zgodzi się, że nie może podjąć Commitmentu dla określonego elementu Product Backlogu, wybiera inny element i powtarza proces Tasks – Godziny – Commitment, aż ktoś powie, że nie może podjąć Commitmentu dla wybranego elementu.

Jeśli tak jest, członkowie zespołu omawiają sytuację i sprawdzają, czy ktoś inny może im pomóc. Być może administrator baz danych z podstawową znajomością JavaScript mógłby pomóc przeciążonemu developerowi JavaScript.

Jeśli nie, Story może zostać odesłana do Backlogu i można wybrać mniejszy lub prostszy element, co do którego każdy może podjąć Commitment.

Co ze Story Points i Velocity?

Być może zauważyłeś, że w tym procesie jak dotąd ani Story Points, ani Velocity nie odgrywały żadnej roli. Nadal zalecam szacowanie elementów Product Backlogu za pomocą Story Points. Jednak Story Points i Velocity nie odgrywają jak dotąd żadnej realnej roli w planowaniu Sprintu opartym na Commitment. Ważną rolę odgrywają jednak w ostatniej fazie spotkania planowania Sprintu.

Weryfikacja Commitmentów

Gdy tylko zespół wypełnił dostępny czas w Sprincie, Scrum Master może sprawdzić, ile Story Points dostały wcześniej poszczególne elementy. Wynik przekazuje następnie zespołowi. Zespół może następnie porównać tę liczbę ze swoją średnią lub aktualną Velocity.

Przyjmijmy, że zespół ze średnią Velocity wynoszącą 20 przeprowadza takie spotkanie planowania Sprintu i wybiera elementy, które łącznie dają 19 Story Points. Wybrali te elementy, nie wiedząc, ile Story Points zostało im wcześniej przypisanych.

Gdy Scrum Master poinformuje ich, że wybrali elementy łącznie o wartości 19 punktów i że ich średnia Velocity jest równa lub bardzo zbliżona, członkowie zespołu mogą założyć, że zaplanowali odpowiednią ilość pracy na Sprint.

Jeśli jednak wybrano jedynie elementy o łącznej wartości 11 Story Points, powinni zapytać siebie, dlaczego teraz uznają pracę za tak dużo trudniejszą.

Może to wynikać na przykład z tego, że w trakcie Sprint Planningu zidentyfikowali pracę, której wcześniej nie uwzględnili. Albo po prostu stwierdzają, że Story jest w rzeczywistości bardziej skomplikowana, niż myśleli.

W każdym przypadku zespół będzie wiedział, czy wybrał odpowiednią ilość pracy, czy też może zaplanować jeszcze więcej.

Z drugiej strony członkowie zespołu będą się zastanawiać, czego nie wzięli pod uwagę, jeśli wybrali elementy łącznie o wartości 30 punktów – czyli 10 więcej niż wynosi ich średnia. Pytanie mogłoby wtedy brzmieć: „Dlaczego ta praca wydaje się po Sprint Planningu tak dużo prostsza niż wcześniej?"

Velocity i Story Points nie odgrywają więc żadnej roli przez większą część spotkania planowania Sprintu opartego na Commitment. Są jednak niezbędne, gdy chodzi o weryfikację i potwierdzenie planowania.

Commitment nie jest gwarancją

Ważne jest, aby nigdy nie traktować Commitmentu jako gwarancji czegoś. Jak powiedział Clint Eastwood w jednym ze swoich filmów: „Jeśli chcesz gwarancji, kup sobie toster!"

Commitment zespołu oznacza, że wszyscy dają z siebie wszystko. Jeśli mogą dotrzymywać swoich Commitmentów w 80 procentach przypadków, jest to dobry wynik. Oznacza to również, że powinni poważnie traktować sprawę i optymalnie wykorzystywać czas. To buduje zaufanie do zespołu i do tego, co twierdzi, że jest w stanie osiągnąć.

Jednak celem nie powinno być zawsze kończenie wszystkiego w 100 procentach. Zespół zmuszany do zawsze kończenia wszystkiego owszem to osiągnie – ale tylko obniżając swoje Commitmenty.

Nazwałem to podejście „Planowaniem Sprintu opartym na Commitment". Nazywane jest ono jednak również „Planowaniem opartym na pojemności". Ten termin coraz bardziej mi się podoba, ponieważ Commitment zbyt łatwo może być rozumiany jako gwarancja.

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