Czym jest Poker Planning?

Poker Planning – czym jest?

Jest to technika estymowania złożoności zadań zaczerpnięta z metodyki zwinnej. Używa się jej przede wszystkim do szacowania złożoności historyjek użytkownika (tzw. user stories) z Product Backlog’a. Historyjki te polegają na zapisywaniu wymagań funkcjonalnych klienta. Powinny prezentować stosunkowo niewielką funkcjonalność, najlepiej taką, która możliwa jest do zaimplementowania w ciągu kilku dni, przy niewielkim nakładzie osób.

Dla dokładniejszego zobrazowania techniki przedstawiliśmy 6 atrybutów dobrze napisanej historyjki według Williama Wake’a:

• Istniejące samodzielnie (ang. Independent)
• Negocjowalne (ang. Negotiable)
• Wartościowe (ang. Valuable)
• Estymowalne (ang. Estimable)
• Małe (ang. Small)
• Testowalne (ang. Testable)
• Zawierające Story Point

W procesie estymowania bierze udział cały zespół, tak aby każdy mógł wyrazić swoją opinię. Niezbędna jest też obecność Product Owner’a lub PM’a, który ma za zadanie wytłumaczyć szczegóły historyjki oraz określić kryteria ich akceptacji.

Jak używać techniki Poker Planning?

Proces gry rozpoczyna się gdy każdy członek zespołu projektowego otrzymuje zestaw kart z wartościami: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 i 100. Będą one służyły do określenia ilości Story Points danej historyjki. Czasem talie uzupełnione są jeszcze o trzy karty – z kawą („czas na przerwę”), ze znakiem zapytania („nie mam pojęcia”) oraz znakiem nieskończoności („Historyjka jest zbyt duża do oszacowania”).

Przebieg gry:

1. Ustalenie punktu odniesienia, czyli przedstawienie wyjściowej, prostej historyjki o wartości np. 1 Story Point.
2. Product Owner / PM omawia historyjkę i odpowiada na ewentualne pytania członków zespołu.
3. Product Owner/PM liczy do trzech i wszyscy jednocześnie wyciągają kartę z wartością mówiącą, ile Story Points powinna ich zdaniem mieć szacowana historyjka (relatywnie w odniesieniu do wyjściowej historyjki).
4. Osoby, które przedstawiły najniższą i najwyższą wartość tłumaczą, dlaczego dokonali takiego wyboru. Następuje przedstawienie argumentów stojących za daną estymacją.
5. Ponowne głosowanie.
6. Kiedy udaje się dojść do porozumienia, następuje przejście do kolejnej historyjki.

Informacje dodatkowe dotyczące przebiegu gry:

• Product Owner / PM nie uczestniczą w estymowaniu.
• Jeśli po 3-4 rundach uczestnicy nie będą w stanie dojść do porozumienia, oznacza to, że historyjka wymaga doprecyzowania.
• Jeśli wynikiem szacowania jest nieskończoność, oznacza to, że historyjka jest za duża do oszacowania i należy ją podzielić na mniejsze, łatwiejsze historyjki.
• Jeśli któryś z członków zespołu pokaże kartę ze znakiem „?”, oznacza to, że historyjka wymaga dalszego wyjaśnienia.
• Jeśli któryś z członków zespołu pokaże kartę symbolizującą kawę, znaczy, że czas na przerwę.
• Alternatywne do liczenia do 3 jest również wykładanie kart na stół (wartością do blatu) i odkrywanie kart, kiedy już wszyscy uczestnicy wyłożą swoje karty.

Dlaczego zastosowanie techniki Poker Planning jest przydatne?

Metoda ta pozwala na estymowanie złożoności zadań, dzięki czemu projekty realizowane są znacznie sprawniej. Dodatkowo członkowie podczas gry nie mogą sugerować się opinią innych, co znacznie zwiększa wiarygodność estymacji zadań. Ale to nie wszystkie zalety, które posiada ta technika. Jej zastosowanie wpływa na 2 kluczowe aspekty związane z zarządzaniem projektami. Sprawdź, jakie korzyści zyskasz w ramach obszaru twardego i miękkiego.

Aspekt twardy – „rozumiem co i wiem jak”

• Zrozumienie zakresu prac, które podlegają estymacji.
• Wychwycenie ewentualnych braków w ustaleniach lub przewidywanie „co jeśli?”
• Rozstrzygnięcie niejasnych kwestii już na poziomie estymowania.
• Zwiększenie precyzji ustaleń w toku dyskusji.
• Wykorzystanie wiedzy całego zespołu, w tym wiedzy osób kompetentnych, odpowiedzialnych za realizację.
• Zrozumienie sposobu realizacji zadań.

Aspekt miękki – „dzielę się wiedzą, komunikuję się, integruję, czuję się odpowiedzialny”

• Wymiana doświadczeń pomiędzy członkami zespołu.
• Za wspólnie wypracowane wartości odpowiada cały zespół, a nie tylko Product Owner / PM.
• Element integrujący, odskocznia od formalnych spotkań.