Jak przeprowadzić Planning Poker krok po kroku

Planning Poker działa, gdy karty wywołują wartościową dyskusję — nie gdy zespół próbuje zgadnąć „właściwą” liczbę. Dobra sesja zapewnia wszystkim ten sam kontekst backlogu, chroni niezależne oceny do momentu ujawnienia i wykorzystuje różne szacunki, aby ujawnić założenia przed rozpoczęciem sprintu.

Ten przewodnik dostarcza powtarzalną agendę dla jednego facylitatora, jednego Product Ownera lub właściciela backlogu oraz osób pomagających realizować zadania.

W tym przewodniku

• Krótka wersja
• Przygotuj backlog i uczestników
• Skorzystaj z praktycznej, 45-minutowej agendy
• Kalibruj i przedstaw każdy element
• Głosuj, ujawnij i omów rozrzut
• Ponów głosowanie, podziel lub zrób pauzę
• Przeanalizuj przykład pięciu elementów
• Unikaj powszechnych błędów
• Skorzystaj z listy kontrolnej facylitatora

Krótka wersja

Dla każdego elementu backlogu:

1. Wyjaśnij oczekiwany rezultat dla użytkownika, zakres i kryteria akceptacji.
2. Pozwól zespołowi zadawać pytania wyjaśniające.
3. Poproś każdego osoby szacujące o prywatny wybór karty.
4. Ujawnij wszystkie karty jednocześnie.
5. Jeśli rozrzut ma znaczenie, wysłuchaj uzasadnień niskich i wysokich ocen.
6. Wyjaśnij element, podziel go w razie potrzeby i ponownie przeprowadź głosowanie.
7. Zapisz szacunek, na którym zespół się zgodził, a następnie przejdź do kolejnego elementu.

Planning Poker to praktyka szacowania, a nie obowiązkowe wydarzenie Scrum. Obowiązujący Scrum Guide pozostawia metody szacowania zespołowi, podkreślając, że osoby wykonujące pracę są odpowiedzialne za oszacowanie elementów Product Backlog.

Przed sesją: przygotuj pracę, którą można przedyskutować

Pokój do głosowania nie zastąpi elementu backlogu, którego nikt nie rozumie. Przygotuj niewielki zestaw najbliższych elementów zamiast całego backlogu.

Dla każdego elementu upewnij się, że zespół widzi:

• wynik dla użytkownika lub biznesu;
• co jest wliczone i co jest wyraźnie wykluczone;
• warunki akceptacji lub przykład oczekiwanego zachowania;
• znane zależności, ograniczenia i systemy wpływane;
• otwarte pytania, które mogą wpłynąć na rozmiar;
• link do pomocnych projektów lub kontekstu technicznego, gdy jest istotny.

Nie usuwaj wszystkich niepewności przed szacowaniem. Niepewność jest częścią tego, co szacunek powinien ujawnić. Jednak zespół potrzebuje wystarczającego kontekstu, aby odróżnić drobny szczegół implementacyjny od nierozstrzygniętej decyzji produktowej.

Wybierz jedną skalę przed rozpoczęciem głosowania

Wiele zespołów używa sekwencji podobnej do Fibonacciego, np. 1, 2, 3, 5, 8, 13, 21. Rosnące odstępy odzwierciedlają, że pewność zwykle maleje, gdy praca staje się większa lub mniej zrozumiała. Agilo obsługuje też inne wbudowane skale i własne zestawy kart.

Traktuj punkty (story points) jako względne, specyficzne dla zespołu rozmiary. 5 jest użyteczne, bo zespół rozumie, jak wypada względem jego 2 lub 8; nie jest to uniwersalna liczba godzin i nie powinno się jej kopiować między zespołami jako tabela konwersji.

Zaproś odpowiednie osoby

Osoby odpowiedzialne za realizację prac powinny głosować. Product Owner lub właściciel backlogu wyjaśnia cele, priorytety i kompromisy. Facylitator pilnuje przebiegu, daje przestrzeń cichszym uczestnikom i zapobiega przekształceniu dyskusji w negocjacje o preferowaną liczbę.

W Agilo uczestnicy potrzebują kont, aby dołączyć do pokoju i głosować. Utwórz pokój przed sesją, wybierz system szacowania, dodaj lub zaimportuj pierwsze elementy i udostępnij zaproszenie z wystarczającym wyprzedzeniem, by wszyscy mogli dołączyć.

Aktualny interfejs Agilo: ośmiu fikcyjnych uczestników oddało głosy, które pozostają ukryte do momentu ujawnienia.

Praktyczna, 45-minutowa agenda

Użyj tego jako punktu wyjścia, następnie dostosuj do ilości i złożoności elementów.

Pięć dobrze przygotowanych elementów jest często bardziej wartościowe niż piętnaście pośpiesznych głosów. Jeśli zespół często potrzebuje długiego discovery podczas sesji, przenieś te elementy z powrotem do refinamentu i skup Planning Poker na pracy gotowej do rozmowy o rozmiarze.

Krok 1: skalibruj się na znanym odniesieniu

Zacznij od niedawno ukończonego elementu, którego kształt zespół pamięta. Nie chodzi o przerabianie historii w celu uzyskania idealnej oceny. Chodzi o wspólne odniesienie: „Ten element miał jedną zmianę UI, jedną zmianę API i znane pokrycie testami; dla nas to 3.”

Używaj odniesień z tego samego zespołu i obszaru produktowego, jeśli to możliwe. 5 zespołu mobilnego i 5 zespołu platformowego nie muszą oznaczać tego samego.

Dla konkretnej skali odniesienia porównaj te sześć przykładów punktów historii, w tym granice akceptacji, które powodują, że element jest mniejszy lub większy.

Krok 2: przedstaw jeden element backlogu

Właściciel backlogu w kilku minutach wyjaśnia rezultat i granice. Unikaj omawiania proponowanej implementacji tak, jakby była już ustalona. Programiści mogą zauważyć prostszą ścieżkę lub zależność zmieniającą cały szacunek.

Przydatne otwarcie brzmi tak:

Zalogowany użytkownik może wyeksportować aktualny raport jako CSV. Ta runda obejmuje widoczne filtry tabeli, ale nie zaplanowane eksporty ani niestandardowe mapowanie kolumn.

Następnie pozwól zespołowi zadawać pytania. Jeśli pytanie zmienia zakres, zaktualizuj element przed głosowaniem.

Krok 3: głosuj prywatnie i ujawnij razem

Każdy szacujący wybiera kartę, nie widząc wyborów innych. Ukryte głosy redukują efekt kotwicy na pierwszą liczbę, najbardziej doświadczoną osobę lub oczekiwania facylitatora.

Ujawnij dopiero po oddaniu głosów przez wszystkich. Agilo może ujawnić karty ręcznie lub automatycznie po głosach wszystkich uczestników, w zależności od ustawień pokoju. Facylitator może też użyć timera pokoju, gdy zespół potrzebuje łagodnej granicy na pytania lub głosowanie.

Nie spiesz się z osobami wybierającymi ?. Ta karta jest użytecznym dowodem: element może brakować kontekstu, nie należeć do czyjejś specjalizacji lub zawierać założenie, które warto uwidocznić.

Krok 4: omów rozrzut, nie każdą liczbę

Jeśli głosy skupiają się wokół sąsiadujących wartości, zespół może potrzebować tylko krótkiego potwierdzenia. Jeśli rozrzut jest szeroki — np. 3, 3, 5, 8, 13 — zacznij od uzasadnień dla najniższej i najwyższej oceny.

Zadaj pytania takie jak:

• Co zawiera 13, czego nie ma 3?
• Czy jest zależność lub ryzyko awarii, które inni przeoczyli?
• Czy szacujemy te same warunki akceptacji?
• Czy ktoś zakłada istnienie infrastruktury wielokrotnego użytku, która jeszcze nie istnieje?
• Czy podział elementu usunąłby główną niepewność?

Celem jest wspólne zrozumienie. Konsensus może być następstwem, ale wymuszanie na wszystkich tej samej karty bez rozwiązania podstawowej różnicy niweczy ćwiczenie.

Gdy jedna osoba głosuje 3, a inna 13: dobra wiadomość — karty nie są uszkodzone. Zespół właśnie rozpoczął potrzebną mu rozmowę. 😅

Aktualny interfejs Agilo po ujawnieniu: rozrzut 3–8 zachęca do porównania założeń. Średnia 5,3 to kontekst, a nie automatyczna ostateczna odpowiedź.

Krok 5: wyjaśnij, podziel lub zagłosuj ponownie

Po dyskusji wybierz jedną z trzech opcji:

1. Ponownie głosuj. Element jest jasny, a nowe informacje zmieniły opinię zespołu.
2. Podziel element. Szacunek jest duży, ponieważ połączono kilka rezultatów lub kroków technicznych.
3. Zatrzymaj szacowanie. Najpierw trzeba rozstrzygnąć decyzję produktową, zależność lub dochodzenie.

Agilo umożliwia kolejną rundę głosowania, ale nie wybiera ostatecznej estymacji dla zespołu. Koordynator i osoby szacujące decydują nadal, która wartość najlepiej odzwierciedla ich wspólne zrozumienie.

Krok 6: zapisz wynik i przejdź dalej

Gdy zespół zgodzi się na estymację, zapisz ją przy elemencie backlogu i wybierz kolejny element podczas trwającej sesji. Jeśli korzystasz z integracji Agilo z Jira, możesz importować zadania Jira z ich kontekstem i zwrócić wybraną estymację po skonfigurowaniu synchronizacji.

Prowadź osobne notatki dotyczące pytań do wyjaśnienia. Nie ukrywaj nierozstrzygniętego zakresu za liczbą tylko po to, by zakończyć listę.

Przykład praktyczny: pięć elementów backlogu

Poniższe wartości należą do fikcyjnego zespołu produktowego korzystającego z własnych elementów referencyjnych. Są przykładami rozumowania, nie uniwersalnym kluczem odpowiedzi.

Weź pod uwagę element widżetu. Głosujący nisko wyobrażali sobie tylko zmianę układu na pulpicie. Głosujący wysoko brali pod uwagę gesty mobilne, zachowaną kolejność, dostępność klawiaturową oraz migrację istniejących układów. Żadne uśrednianie nie rozwiązałoby tej rozbieżności. Podzielenie elementu uczyniło zakres jasnym i wygenerowało dwie bardziej wartościowe dyskusje.

Typowe błędy osłabiające sesję

Traktowanie średniej jako odpowiedzi

Średnia może ukrywać dwie niezgodne interpretacje. Najpierw omów rozrzut. Ostateczna estymacja powinna odzwierciedlać zrozumiany zakres pracy, a nie arytmetyczną wygodę.

Pozwalanie najbardziej doświadczonej osobie głosować na głos

Gdy jedna liczba zostanie wypowiedziana, kolejne estymacje zwykle się do niej dostosowują. Trzymaj karty zakryte do momentu ujawnienia i pytaj o uzasadnienie po niezależnym głosowaniu.

Debatowanie nad implementacją zanim wynik będzie jasny

Dyskusja techniczna jest cenna, ale dopiero gdy wszyscy rozumieją, co element ma osiągnąć. W przeciwnym razie zespół może szacować różne produkty.

Wymuszanie estymacji dla niegotowego elementu

„Potrzebujemy dziś liczby” nie usuwa zależności. Zaznacz pytanie, wyznacz odpowiedzialnego i wróć, gdy brakująca decyzja będzie dostępna.

Porównywanie osób lub zespołów na podstawie punktów historii

Punkty są narzędziem lokalnego planowania. Przekształcanie ich w cel wydajnościowy zachęca do zawyżania i obniża wartość estymacji.

Lista kontrolna koordynatora

Przed spotkaniem:

• wybierz 5–8 najbliższych elementów;
• dodaj kontekst i kryteria akceptacji;
• utwórz pokój i wybierz zestaw kart;
• potwierdź, kto wyjaśni elementy, a kto będzie głosował;
• wybierz jeden znany element referencyjny.

Podczas każdej rundy:

• ukrywaj głosy aż wszyscy będą gotowi;
• wysłuchaj uzasadnień najniższych i najwyższych głosów, gdy rozrzut jest istotny;
• aktualizuj element przy zmianie założeń;
• powtórz głosowanie, podziel lub wstrzymaj zamiast wymuszać zgodę;
• zapisz wybraną estymację i ewentualnego właściciela dalszych działań.

Po spotkaniu:

• upewnij się, że estymacje są widoczne w backlogu;
• rozwiąż wstrzymane elementy przed planowaniem sprintu;
• ponownie rozważ skalę tylko, gdy zespół uzna ją za stale nieprzydatną.

Uruchom proces w Agilo

Agilo Planning Poker zachowuje kontekst backlogu, prywatne głosowanie, jednoczesne ujawnienie, powtarzające się rundy i wybraną estymację w jednym pokoju. Możesz dodawać prace ręcznie lub importować zadania Jira, korzystać z wbudowanego lub własnego zestawu kart oraz przejść od razu do kolejnego elementu po zgodzie zespołu.

Utwórz pokój Planning Poker, gdy Twoje elementy backlogu i uczestnicy będą gotowi.

Źródła i dalsza lektura

• Agile Alliance: Planning Poker — podstawowy wzorzec prywatnego głosowania, jednoczesnego ujawnienia, dyskusji i dodatkowych rund.
• Oficjalny Scrum Guide — aktualna definicja Scruma i odpowiedzialności za rozmiar Product Backlogu.