Jak przeprowadzić planning poker krok po kroku

Planning poker to technika estymacji oparta na konsensusie. Każdy członek zespołu prywatnie wybiera kartę odpowiadającą nakładowi pracy, wszyscy odkrywają ją jednocześnie, a zespół omawia różnice, aż uzgodni wspólną estymatę. To jedna z najczęściej stosowanych technik eksperckiej estymacji w badaniach nad estymacją agile. Potrzebujesz zespołu, listy elementów do oszacowania i talii, a następnie wykonujesz siedem kroków opisanych poniżej.

Czym jest planning poker?

Planning poker (zwany też scrum poker lub pointing poker) zmienia estymację w krótką, uporządkowaną grę. Zamiast pozwolić najgłośniejszej lub najbardziej doświadczonej osobie wybrać liczbę, każdy samodzielnie podejmuje decyzję, a następnie wszyscy odkrywają karty naraz. Ta jedna zasada — jednoczesne odkrywanie — sprawia, że metoda działa.

Dlaczego to działa: nauka wspólnego szacowania

Karty w planning poker są odkrywane jednocześnie, aby uniknąć efektu zakotwiczenia — dobrze opisanego błędu poznawczego, w którym pierwsza podana liczba przyciąga ku sobie pozostałe estymaty. W kontrolowanych eksperymentach samo pokazanie specjalistom IT dowolnej liczby przed szacowaniem silnie przesuwało ich wyniki w jej kierunku. Efekt był duży, a warsztaty mające go ograniczyć jedynie osłabiały wpływ kotwicy, zamiast go usuwać. Zakotwiczenie od dawna wskazuje się jako ważną przyczynę zbyt optymistycznych estymat pracy programistycznej.

Pomaga również estymowanie w grupie. W badaniu, w którym planning poker zastosowano do rzeczywistych zadań projektowych, uzgodniona po dyskusji estymata zespołu była mniej optymistyczna niż średnia indywidualnych szacunków i lepiej odpowiadała rzeczywistemu nakładowi pracy. (Pełne źródła znajdują się poniżej).

Co przygotować

• Zespół osób, które wykonają pracę (zwykle od 3 do 9).
• Uporządkowaną listę historyjek użytkownika lub zadań do oszacowania.
• Talię do estymacji (zobacz krok 2).
• Osobę prowadzącą (często Scrum Mastera) oraz kogoś, kto odpowie na pytania dotyczące elementów (często Product Ownera).

Jak przeprowadzić planning poker: 7 kroków

1. Przygotuj pokój i zaproś zespół. Utwórz sesję i udostępnij link. W Planning Poker Web — darmowym narzędziu planning poker — każdy może dołączyć bez konta: wystarczy otworzyć link. Wskazówka dla prowadzącego: przed rozpoczęciem ustalcie talię i historyjkę referencyjną („mały błąd = 2 punkty”), aby wszyscy korzystali z tej samej skali.
2. Wybierz talię estymacyjną. Wybierz skalę, w której będzie głosował zespół (Fibonacci, rozmiary koszulek itp.). Wskazówka: używaj tej samej talii przez kolejne sprinty, aby porównywać velocity.
3. Przedstaw pierwszą historyjkę użytkownika. Product Owner czyta element i odpowiada na pytania. Prezentacja powinna być krótka — szczegóły wyjdą podczas dyskusji. Ustal limit czasu: około 2 minuty.
4. Wszyscy głosują jednocześnie. Każdy prywatnie wybiera kartę odpowiadającą jego ocenie nakładu pracy. Na tym etapie nikt nie podaje liczb na głos. Wskazówka: uwzględnij wszystkie osoby wykonujące pracę, także testerów i projektantów, nie tylko programistów.
5. Odkryjcie karty jednocześnie. Gdy wszyscy zagłosują, odkryjcie karty naraz. To krok zapobiegający zakotwiczeniu: głos nikogo nie został ukształtowany cudzą decyzją.
6. Omówcie skrajne wyniki. Jeśli estymaty się różnią, osoby z najwyższą i najniższą kartą wyjaśniają swoje rozumowanie. Dzięki temu wychodzą na jaw ukryte założenia, pominięte zadania i ryzyka — często najcenniejsza część sesji. Przeznacz na to około 3–5 minut. Jeśli dyskusja trwa dłużej, historyjka może być zbyt duża.
7. Głosujcie ponownie, aż osiągniecie porozumienie. Po dyskusji zagłosujcie jeszcze raz. Powtarzajcie, aż zespół uzgodni wspólną wartość. Zapiszcie ją i przejdźcie do następnego elementu. „Porozumienie” nie wymaga identycznych kart — wystarczy zgodność, więc nie dążcie do jednomyślności za wszelką cenę.

Przykład: estymacja historyjki użytkownika

Załóżmy, że historyjka brzmi: „Użytkownik może zresetować hasło przez e-mail”. Product Owner ją odczytuje, a tester pyta, czy w zakresie jest ograniczanie liczby prób (jest). Zespół głosuje talią Fibonacciego i odkrywa karty:

Tester (8) wyjaśnia, że przepływ resetowania wymaga ograniczania liczby prób, przygotowania szablonu e-maila i obsługi wygasłych tokenów — nikt inny nie uwzględnił tych elementów. Właśnie takie ukryte zadania planning poker pomaga odkrywać. Po dyskusji zespół głosuje ponownie (5, 5, 8, 5) i uzgadnia 5. Sama liczba jest mniej ważna niż to, że cały zespół ma teraz wspólne rozumienie pracy.

Planning poker zdalnie i stacjonarnie

Zasady są takie same, różni się sposób prowadzenia.

• Stacjonarnie: można używać fizycznych kart, ale ktoś musi przepisać wyniki i nie ma automatycznej historii. Uważaj na osoby odkrywające karty z opóźnieniem i wpływające na innych.
• Zdalnie lub w rozproszonym zespole: niezbędny jest wspólny pokój online. Narzędzie wymusza jednoczesne odkrycie (nikt nie widzi wcześniejszych głosów), automatycznie zapisuje wyniki i historię, a głosowanie asynchroniczne pozwala zespołom w różnych strefach czasowych pracować bez rozmowy na żywo. W takiej sytuacji Planning Poker Web całkowicie zastępuje fizyczną talię. Zobacz poradnik planning poker dla zespołów zdalnych, aby poznać tryb na żywo i asynchroniczny.

Kiedy NIE używać planning poker

Planning poker nie zawsze jest najlepszym narzędziem. Zrezygnuj z niego lub wybierz szybszą metodę, gdy:

• Backlog jest ogromny (ponad 50 elementów). Głosowanie nad każdym elementem potrwa zbyt długo. Najpierw użyj estymacji przez podobieństwo lub metody kubełkowej, a planning poker zastosuj tylko do niepewnych elementów.
• Za pracę jednoznacznie odpowiada jedna osoba. Gdy nie ma różnych perspektyw, grupowa ceremonia niewiele wnosi w porównaniu z szybką oceną eksperta.
• Zespół ma już wspólne rozumienie pracy. Przy dobrze znanych, powtarzalnych zadaniach estymaty rzadko się różnią, więc dyskusja niewiele wnosi.
• Szacujesz długoterminową mapę drogową, a nie sprint. Wystarczy przybliżona ocena (rozmiary koszulek); precyzyjne punkty względne na tak odległą przyszłość to zbędny wysiłek.

Szczerość w tych sprawach buduje zaufanie. Zespoły zaczynają nie lubić estymacji, gdy planning poker jest wymuszany w sytuacjach, do których nie pasuje.

Trudne sytuacje i sposoby radzenia sobie z nimi

• Zespół nie może uzgodnić wyniku po dwóch rundach. Historyjka jest zwykle zbyt duża lub niejasna. Podziel ją albo poproś Product Ownera o doprecyzowanie.
• Jedna osoba dominuje dyskusję. Prywatne głosowanie już ogranicza ten wpływ. Dodatkowo poproś o wypowiedź osobę z najniższą kartą zamiast najbardziej doświadczonej.
• Ktoś zawsze głosuje jak większość. Poproś tę osobę o oddanie głosu, zanim pozna stanowisko zespołu. W narzędziu głosy są ukryte do czasu odkrycia, więc pokusa znika.
• Estymaty są stale zbyt niskie. To efekt nadmiernego optymizmu i zakotwiczenia. Ustal widoczną historyjkę referencyjną i porównuj z nią nowe elementy zamiast szacować w próżni.

Planning poker a inne techniki estymacji

Częste błędy, których warto unikać

• Podawanie liczby przed odkryciem kart, co ponownie wprowadza zakotwiczenie.
• Szacowanie w godzinach zamiast punktów względnych. Szacowanie względne jest szybsze i mniej obciążone błędami.
• Obliczanie średniej zamiast dyskusji. Dyskusja jest celem, liczba — jej wynikiem.
• Pozwalanie jednej osobie zdominować rozmowę. Prywatne głosowanie ma temu zapobiegać.
• Głosowanie bez końca. Dążenie do identycznych kart marnuje czas — celem jest wystarczająca zgodność.

Słowniczek pojęć planning poker

• Story point: jednostka względnego nakładu pracy (nie liczba godzin), uwzględniająca złożoność, niepewność i ilość pracy.
• Talia: zestaw kart używanych podczas głosowania (np. Fibonacci, rozmiary koszulek).
• Velocity: liczba punktów realizowanych przez zespół w sprincie; służy do prognozowania, nie do porównywania zespołów.
• Zakotwiczenie: błąd poznawczy, w którym pierwsza podana liczba przyciąga ku sobie pozostałe estymaty; dlatego głosy odkrywa się jednocześnie.
• Wynik skrajny: najwyższy lub najniższy głos, którego uzasadnienie zespół omawia w pierwszej kolejności.
• Historyjka referencyjna: wcześniej oszacowany element służący zespołowi za punkt odniesienia i pomagający zachować stałą skalę.

Często zadawane pytania

Ile trwa sesja planning poker?

Dla typowego backlogu sprintu od 30 do 60 minut. Oszacowanie jednego elementu zajmuje zwykle 1–3 minuty, chyba że rozbieżności wymagają dłuższej rozmowy.

Ile osób powinno uczestniczyć?

Zwykle od 3 do 9 osób, które faktycznie wykonają pracę. Przy mniej niż trzech osobach zespół traci różnorodność perspektyw, a więcej niż dziewięć spowalnia dyskusję.

Jakiej talii użyć?

Domyślnie często wybiera się Fibonacci (0, 1, 2, 3, 5, 8, 13 i więcej), ponieważ rosnące odstępy odzwierciedlają większą niepewność przy większych elementach. Do wstępnego szacowania dobrze nadają się rozmiary koszulek.

Dlaczego wszystkie karty odkrywa się jednocześnie?

Aby zapobiec zakotwiczeniu — wpływowi pierwszej wypowiedzianej liczby na pozostałe estymaty. Jednoczesne odkrycie zapewnia niezależność głosów.

Szacować w godzinach czy punktach?

Zalecamy punkty względne (story points). Łatwiej je uzgodnić i są mniej podatne na błąd nadmiernego optymizmu, który badania wykazują przy estymatach godzinowych.

Co zrobić, jeśli zespół nie może się zgodzić?

Poproś osoby z najwyższą i najniższą kartą o wyjaśnienie, a następnie zagłosujcie ponownie. Jeśli nadal nie możecie uzgodnić wyniku, element jest prawdopodobnie zbyt duży lub niejasny — podziel go albo poproś o doprecyzowanie.

Czy można przeprowadzić planning poker asynchronicznie?

Tak. W narzędziu online członkowie zespołu głosują w dogodnym czasie, a karty są odkrywane, gdy wszyscy zagłosują. Sprawdza się to w rozproszonych zespołach w różnych strefach czasowych. Głosy pozostają ukryte do chwili odkrycia, więc korzyść w postaci ograniczenia zakotwiczenia jest zachowana.

Kto powinien uczestniczyć i czy Scrum Master powinien głosować?

Wszystkie osoby wykonujące pracę (programiści, testerzy, projektanci). Scrum Master zwykle prowadzi sesję zamiast głosować, a Product Owner odpowiada na pytania, ale nie estymuje.

Czy planning poker to to samo co scrum poker?

Tak. „Scrum poker” i „pointing poker” to popularne synonimy tej samej metody.

Źródła

1. Moløkken-Østvold, Haugen i Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106–2117.
2. Mahnič i Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086–2095.
3. Jørgensen i Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula.
4. Løhre i Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software.
5. Shepperd i in. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919.