Planning poker – przyjemne z pożytecznym
Planning poker to metoda zwinnego estymowania projektów spopularyzowana przez Mike Cohna (BTW, jestem jego fanką :D!). Połączenie tej metody estymaty ze story points to dla mnie dobrze rokująca receptura.
Skutki uboczne, które dostrzegam z zastosowania tej metody to: dobra zabawa i wzmocnienie/ budowa silniejszych relacji w zespole.
Jak to działa?
Opiszę na podstawie estymaty, w której do szacowania wykorzystuje się punkty zwane story points.
Do dyspozycji dla każdego szacującego są karty, o określonych wartościach (story points). Wartości, których ja używam do estymaty to zmodyfikowany ciąg Fibonacciego, z następującym znaczeniem:
0 – zadanie za małe, by przyznać mu punkty/ zadanie nie wymaga pracy po naszej stronie
1 – małe zadanie, bez ryzyka, bez niepewności, nieskomplikowane, wymagające minimalnego nakładu pracy
2 – zadanie 2 razy większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 1
3 – zadanie 3 razy większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 1
5 – zadanie 2.5 raza większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 2
8 – zadanie 2,5 raza większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 3
13 – zadanie około 2,5 raza większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 5
20 – zadanie 5 razy większe/bardziej skomplikowane/o większym ryzyku lub niepewności niż to estymowane na 5
40 – zadanie bardzo duże, bardzo złożone, o dużym stopniu ryzyka i niepewności, zwykle wymaga podziału na mniejsze zadania.
100 – za duże, by estymować
Co należy brać pod uwagę, przyznając punkty poszczególnym user stories:
- Złożoność zadania
- Ilość pracy do wykonania
- Niepewność względem estymowanego zadania/jego zakresu
- Ryzyko wiążące się z estymowanym zadaniem.
Jak przebiega planning poker?
- Wybieramy user stories, które mają być oszacowane podczas sesji.
- Jedna osoba czyta na głos wybrane user stories. To czas na objaśnienia i pytania, jednak nie należy poświęcać więcej niż 2 minuty na to.
- Każdy biorący udział w estymacie wykłada kartę na stół z odpowiednią ilością punktów (punktami do dołu, by pozostali nie widzieli). Można skorzystać również z narzędzia online do planning pokera, np. aplikacji Magic Estimatation w Jirze — działa ona na tych samych zasadach — dopóki wszyscy estymujący nie wyłożą swoich kart (nie przyporządkują ilości punktów estymowanemu user stories w aplikacji) pozostali gracze nie wiedzą, jak estymowali inni. Karty są odsłaniane w tym samym momencie.
- W przypadku rozbieżności w estymacie następuje konwersacja, która jest kluczowa w zwinnym estymowaniu projektów. Może się okazać, że jedna osoba ma istotne informacje na temat estymowanego zadania, które mają znaczenie dla estymaty.
- Po przedyskutowaniu zadania i tego, dlaczego poszczególni gracze dali taką, a nie inną ilość punktów, następuje ponowna jego estymata na takich samych zasadach jak opisane wyżej. Cykl jest powtarzany do momentu, aż wszyscy uczestnicy estymaty zgodzą się co do jej wartości, co oznacza, że wszystkie wątpliwości powinny być omówione w trakcie konwersacji.
Celem sesji nie jest wyciągnięcie średniej wartości, a uzyskanie zgodności, co do wysokości estymaty.
Szybka i prosta metoda, prawda?
A jak taką estymatę przekształcić w estymatę czasową?
Jest na to pewien sposób. Znając długość sprintu, możemy wybrać oszacowane w story points user stories, które będziemy realizować w ramach sprintu i przeliczyć je na jednostki czasowe.
Przykład:
Długość sprintu: 2 tygodnie
Zespół: 3 FTE (full-time-employment).
Ilość rzeczywistych roboczogodzin zespołu przypadająca na sprint*: 3 osoby x 6 h x 10 dni roboczych = 180 h
Ilość story points planowana do wykonania w czasie 1 sprintu: 18 pkt.* pamiętajmy, że nie są to dni idealne, a średnia wydajność 1 osoby w 8-godzinnym dniu pracy to 6 h):
Wybrane user stories, rozbijamy na mniejsze elementy — konkretne techniczne zadania, które należy wykonać, by zrealizować dane user stories. Te zadania estymujemy już w jednostce czasowej. Pamiętamy, że mamy 180h do wykorzystania w ramach sprintu.
Okazuje się, że wyestymowaliśmy user stories o łącznej wartości 16 pkt i mamy już 179h. Przyjmujemy zatem, że w ramach jednego sprintu będziemy w stanie zrealizować 16 pkt, a nie 18 jak zakładaliśmy pierwotnie (to przy założeniu, że cały zespół będzie w 100% dostępny przez cały sprint).
Jeśli projekt wyestymowaliśmy na 500 punktów, to łatwo przeliczyć ile zajmie on sprintów (500 × 16 = 32 sprinty. Jeszcze tylko wystarczy zastosować odpowiedni bufor (więcej tutaj) i wstępna estymata dla interesariuszy gotowa.
