Planning Poker to znacznie więcej niż tylko gra w karty w procesie Scrum. To narzędzie, które może fundamentalnie zmienić sposób, w jaki Twój zespół myśli o szacowaniu i rozumie zakres pracy. Obserwuję to od lat w różnych organizacjach — zespoły, które opanowały sztukę Planning Poker, nie tylko lepiej szacują Story Points, ale przede wszystkim lepiej rozumieją to, co mają zrobić. Obserwuję ciekawe zjawisko w dojrzałych zespołach scrumowych — po kilku miesiącach pracy zaczynają traktować Planning Poker jak dziecko kółka boczne przy rowerze. “Już potrafimy szacować, nie potrzebujemy tych kart”.
Jednak większość organizacji traktuje Planning Poker mechanicznie. Rozdają karty, każdy pokazuje liczbę, ktoś wylicza średnią i gotowe. W tym momencie marnują najważniejszą wartość tej techniki — rozmowę, która prowadzi do wspólnego zrozumienia. Dlaczego ta rozmowa jest tak istotna? Bo Planning Poker to nie narzędzie do przewidywania przyszłości, lecz sposób na odkrywanie różnic w rozumieniu elementu Backlogu Produktu.
Geneza Planning Poker — od Wideband Delphi do kart Fibonacciego
Planning Poker został opracowany przez Jamesa Grenninga i spopularyzowany w świecie Agile przez Mike’a Cohna. Wywodzi się z metody Wideband Delphi — podobnie jak w oryginalnej metodzie, początkowe oszacowania są wyznaczane anonimowo, następnie typowane wielkości są ujawniane, a największe rozbieżności zostają omówione. Jeżeli nie doszło do porozumienia, po dyskusji następuje kolejna iteracja.
Metodę nazwano Planning Poker, ponieważ do szacowania używane są karty do gry i uczetnicy nie widzą jakie karty mają pozostali gracze. Wybrane karty nie są widoczne dla pozostałych uczestników, ponieważ odkrywa się je dopiero na znak moderatora sesji. Niestety, nazwa sugeruje, że jest to narzędzie do planowania, podczas gdy w rzeczywistości służy do szacowania. Chociaż nazwa nawiązuje do Sprint Planning, w praktyce Planning Poker jest najskuteczniejszy podczas sesji Product Backlog Refinement. Oszacowanie pojedynczego elementu potrafi zająć sporo czasu, a celem Refinement jest właśnie przygotowanie elementów, aby na Sprint Planning były już w stanie ‘Ready’. Dzięki temu zespół przychodzi na planowanie sprintu z dobrze zrozumianym i oszacowanym backlogiem, co pozwala skupić się na tworzeniu planu, a nie na estymacji od zera.
Ta różnica między szacowaniem a planowaniem jest kluczowa dla zrozumienia miejsca Planning Poker we frameworku Scrum. Szacujemy Story Points, żeby lepiej rozumieć złożoność elementów Backlogu Produktu i planować capacity zespołu. Ale sam plan sprintu powstaje w oparciu o te szacunki, cele biznesowe i dostępność zespołu.
Karty Planning Poker — znaczenie poszczególnych wartości
Standardowy zestaw kart Planning Poker zawiera liczby z sekwencji Fibonacciego oraz kilka kart specjalnych. Każda ma swoje szczególne znaczenie:
Liczby 1–100 to standardowe wartości oszacowania. Im większa liczba, tym bardziej złożony element Backlogu Produktu. Większość zespołów rzadko używa wartości powyżej 21, co sygnalizuje potrzebę podzielenia User Story.
Karta ½ ma takie samo znaczenie jak pozostałe wartości liczbowe, jednak rzadko używana przez zespoły, ponieważ oznacza zbyt dokładne oszacowanie. W moim doświadczeniu, zespoły sięgające po ½ często mają problem z rozumieniem, że Story Points nie są jednostkami czasu.
Karta 0 oznacza, że element Backlogu Produktu nie wymaga pracy lub jest jej zbyt mało, aby otrzymać za nią punkt. Pierwsza opcja oznacza, że element został już wykonany lub zostanie wykonany przez kogoś spoza zespołu deweloperskiego. Druga — że zespół postrzega go jako trywialny.
Karta ze znakiem zapytania (∞) sygnalizuje, że element Backlogu Produktu jest zbyt duży lub niezrozumiały, żeby go oszacować. To sygnał dla Product Ownera, że potrzeba więcej szczegółów albo User Story należy podzielić.
Karta z filiżanką kawy oznacza, że osoba potrzebuje przerwy. Może wydawać się żartobliwa, ale ma głębszy sens — szacowanie wymaga skupienia, a zmęczony zespół podejmuje gorsze decyzje.
Skala Fibonacciego w Planning Poker — dlaczego właśnie te liczby?
Większość zespołów używa sekwencji Fibonacciego: 1, 2, 3, 5, 8, 13, 21. To nie przypadek ani matematyczna fanaberia. Im większy element Backlogu Produktu, tym trudniej precyzyjnie oszacować wysiłek potrzebny do jego wykonania. Rosnące odstępy między liczbami Fibonacciego odzwierciedlają tę niepewność.
Różnica między 1 a 2 story points jest stosunkowo niewielka — mówimy o elementach, które zespół dobrze rozumie. Ale różnica między 13 a 21 jest już znacząca i sygnalizuje, że User Story może być zbyt duże na jeden sprint. W praktyce, gdy zespół regularnie szacuje User Stories na 13 czy 21 punktów, to znak, że potrzebne jest ich podzielenie na mniejsze części.
Alternatywne skale szacowania:
- Potęgi dwójki (1, 2, 4, 8, 16) — preferowane przez zespoły o technicznym background’zie
- Rozmiary koszulek (XS, S, M, L, XL) — intuicyjne dla nowych zespołów
- #noestimates — dzielenie elementów aż osiągną odpowiednią wielkość
Planning Poker krok po kroku — jak prowadzić szacowanie
Skuteczny Planning Poker to znacznie więcej niż pokazywanie kart. To facylitowany proces, który wymaga odpowiedniego przygotowania i prowadzenia. Oto sprawdzony sposób na przeprowadzenie sesji szacowania:
Krok 1: Przygotowanie zespołu i materiałów
Każdy Developer potrzebuje zestaw kart Planning Poker. Mogą to być fizyczne karty lub aplikacja — ważne, żeby wszyscy mogli równocześnie ujawnić swoje szacunki. Product Owner powinien być obecny, ale nie uczestniczy w szacowaniu. Jego rolą jest wyjaśnianie wymagań i odpowiadanie na pytania.
Krok 2: Prezentacja User Story
Product Owner prezentuje User Story, czyta kryteria akceptacji i wyjaśnia kontekst biznesowy. To moment na zadawanie pytań technicznych i biznesowych. Im lepiej zespół zrozumie User Story, tym bardziej trafne będzie szacowanie. Ale uwaga — nie popadajmy w pułapkę analizy paralitycznej. Czasem trzeba zaakceptować niepewność.
Krok 3: Indywidualne rozważania
Każdy członek zespołu w ciszy zastanawia się nad złożonością elementu Backlogu Produktu. Porównuje go z wcześniej oszacowanymi User Stories. “Czy to jest większe od tej funkcji logowania, którą szacowaliśmy na 5 punktów?” Referencyjne Story Points z poprzednich sprintów stają się kluczowe dla spójności szacowania.
Krok 4: Równoczesne ujawnienie kart
Na sygnał (często “3, 2, 1, pokaż!”) wszyscy równocześnie ujawniają swoje karty. To kluczowy moment — nie ma możliwości dostosowania się do opinii innych. Jeśli szacunki są podobne (różnią się o jeden poziom Fibonacciego), zespół może szybko dojść do konsensusu.
Krok 5: Dyskusja różnic w szacunkach
Gdy szacunki znacząco się różnią, rozpoczyna się najważniejsza część procesu. Osoba, która pokazała najniższą i najwyższą wartość, wyjaśnia swoje rozumowanie. Często okazuje się, że myśleli o różnych aspektach elementu Backlogu Produktu lub mieli różne założenia techniczne.
Krok 6: Ponowne szacowanie
Po dyskusji zespół szacuje ponownie. Zwykle szacunki się zbiegają. Jeśli nadal są bardzo różne, może to oznaczać, że element Backlogu Produktu jest zbyt mało zdefiniowany lub zbyt duży. Wtedy warto przerwać szacowanie i popracować nad lepszym zrozumieniem wymagań.
Praktyczne aspekty organizacji Planning Poker
Pierwsze karty Planning Poker można kupić na stronie Mike’a Cohna w Mountain Goat Software. Jeżeli kilka dolarów przekracza Twój budżet, możesz napisać liczby na fiszkach lub zaprojektować karty w edytorze tekstu i wydrukować na nieco grubszym papierze. Ważne, żeby karty były nieprzeźroczyste — nie chcemy przypadkowego ujawnienia szacunków przed czasem.
Obecnie zespoły, z którymi pracuję, coraz rzadziej sięgają po pudełka z kartami, a coraz częściej po smartfony. Bez trudu można znaleźć kilka odpowiednich aplikacji na platformy Android, iOS i Windows. Dla zespołów rozproszonych geograficznie dostępne są narzędzia webowe jak PlanITPoker.com czy Planning Poker Online.
Przed pierwszą sesją pokera online dobrze jest wykonać rundę testową, aby uczestnicy poznali mechanizmy działania narzędzia i przetestowali połączenie. Nic nie frustruje bardziej niż problemy techniczne w środku sesji.
Dlaczego Planning Poker działa? Zalety potwierdzone praktyką i badaniami
Po latach obserwacji zespołów scrumowych widzę, że sukces Planning Poker wynika z kilku kluczowych czynników:
- Osoby szacujące są tymi, które następnie wykonają pracę. To fundamentalna różnica względem tradycyjnego zarządzania, gdzie szacunki robi manager, a wykonuje zespół. Development Team ma najlepszą wiedzę o tym, ile wysiłku wymaga implementacja.
- Osoby uczestniczące w sesji nie wpływają wzajemnie na swoje oszacowania przed pierwszą rundą. Każdy musi wyrazić własną opinię przed poznaniem szacunków innych. To eliminuje efekt kotwiczenia — psychologiczne zjawisko, gdzie pierwsza usłyszana liczba wpływa na nasze własne szacunki.
- Unikamy dominacji wpływowych osób. W każdym zespole są osoby, których opinia ma większą wagę — seniorzy, architekci, długoletni pracownicy. Planning Poker daje głos wszystkim, niezależnie od hierarchii czy doświadczenia.
- Oszacowania są uzasadniane przez uczestników. To najważniejsza część procesu. Gdy ktoś pokazuje 3, a ktoś inny 13, rozpoczyna się rozmowa. Właśnie w tym momencie ujawnia się psychologiczna siła tej techniki. Konieczność uzasadnienia swojego wyboru zmusza do głębszej, analitycznej refleksji. Potwierdzają to badania nad podejmowaniem decyzji, które wykazały, że sama potrzeba uzasadnienia swoich sądów prowadzi do większej spójności w ocenie, szczególnie w warunkach dużej niepewności i braku natychmiastowej informacji zwrotnej – czyli w sytuacji typowej dla szacowania złożonych elementów Backlogu Produktu w Scrum. Często okazuje się, że uczestnicy myśleli o różnych aspektach elementu Backlogu Produktu lub mieli różne założenia techniczne.
- Skupia się na szacowaniu w odpowiedniej skali wielkości. Sekwencja Fibonacciego uczy zespół myślenia w kategoriach względnej złożoności, nie precyzyjnych godzin. To kluczowe dla zrozumienia, że szacowanie to oszacowanie, nie zobowiązanie.
- Jest metodą szybką i przyjemną. Element “gry” sprawia, że zespół chętniej uczestniczy w procesie. Badania potwierdzają, że pozytywne emocje wpływają na jakość podejmowanych decyzji.
Najczęstsze błędy w Planning Poker i jak ich unikać
Po latach prowadzenia szkoleń Professional Scrum Master i obserwacji zespołów scrumowych widzę, że te same błędy powtarzają się w różnych organizacjach. Nie są to błędy techniczne, ale przede wszystkim kulturowe i komunikacyjne.
Błąd #1: Mechaniczne uśrednianie wyników
Zespół pokazuje karty: 3, 5, 8, 13. Scrum Master szybko liczy: “średnia wychodzi 7, to dajemy 8 story points”. I tu właśnie marnuje się najważniejsza wartość Planning Poker. Prawdziwa magia dzieje się w rozmowie między osobą, która pokazała 3, a tą, która wybrała 13. To nie są różne opinie o tym samym elemencie Backlogu Produktu — to często oznacza, że członkowie zespołu rozumieją go zupełnie inaczej.
Osoba szacująca na 3 może myśleć tylko o happy path, podczas gdy ta pokazująca 13 uwzględnia edge cases’ów i integracje z legacy systemami. Bez tej rozmowy zespół traci szansę na lepsze zrozumienie User Story.
Błąd #2: Dominacja technicznego eksperta
W każdym zespole deweloperskim jest ta jedna osoba, która “wie wszystko”. I często, gdy pokazuje swoją kartę, reszta zespołu podświadomie dostosowuje swoje szacunki. Planning Poker ma eliminować ten efekt, ale tylko jeśli Scrum Master aktywnie zachęca wszystkich do wyrażania własnych opinii i pilnuje, żeby ekspert nie przemawiał pierwszy podczas dyskusji.
Błąd #3: Szacowanie na poziomie tasków
Niektóre zespoły rozbijają User Story na techniczne taski podczas Planning Poker i szacują każdy osobno. To prowadzi do fałszywej precyzji i marnuje czas. Planning Poker ma szacować całą User Story na poziomie biznesowym, nie techniczne szczegóły implementacji.
Błąd #4: Traktowanie jako zawodów w szacowaniu
Zdarza się, że zespół zaczyna traktować Planning Poker jak grę — kto będzie najbliżej “prawdziwego” wyniku. To przeciwność celu tej techniki. Planning Poker to narzędzie konsensualne, nie predykcyjne. Celem nie jest perfekcyjne przewidzenie przyszłości, lecz wspólne zrozumienie elementu Backlogu Produktu.
Jak radzić sobie z rozbieżnościami w szacunkach?
Gdy zespół pokazuje karty z różnymi wartościami, powstaje pytanie: jak dojść do konsensusu? W mojej praktyce sprawdzają się różne podejścia, w zależności od kultury zespołu.
Niektóre zespoły wybierają wartość środkową. Na przykład przy wyniku 3, 8, 5, 5, 8, 3, 8 wybierają 5. Spotkałem się też z obliczeniem średniej i wybraniem karty najbliższej tej średniej. W powyższym przykładzie średnia to 5,71, więc najbliższa karta to 5. Takie podejście zadziała dobrze w przypadku małych różnic. W przypadku dużych rozbieżności średnia ze skrajnych oszacowań będzie dawała znacznie bardziej odległy wynik od rzeczywistej wielkości niż mediana z wszystkich estymat.
Ale prawdziwa wartość Planning Poker nie leży w algorytmie wyboru liczby, lecz w rozmowie o przyczynach rozbieżności.
Dlatego zawsze zachęcam zespoły do przedłużenia dyskusji, zanim przejdą do mechanicznego uśredniania. Osoba pokazująca najniższy i najwyższy szacunek powinna wyjaśnić swoje rozumowanie. Często okazuje się, że różnice wynikają z różnego rozumienia elementu Backlogu Produktu, nie z błędnych kalkulacji.
Planning Poker vs inne techniki szacowania w Agile
Planning Poker to jedna z wielu technik szacowania dostępnych zespołom scrumowym. Kiedy warto rozważyć alternatywy?
Affinity/Wall Estimation sprawdza się świetnie, gdy mamy dużo User Stories do oszacowania jednocześnie. Zespół umieszcza kartki na ścianie w kolejności od najmniejszej do największej, grupując podobne elementy. To szybsze niż Planning Poker, ale daje mniej precyzyjne wyniki.
Sorting/Magic Estimation łączy zalety obu technik — zespół sortuje elementy Backlogu Produktu względem siebie, a potem przypisuje konkretne wartości Story Points. Sprawdza się w Product Backlog Refinement, gdy potrzebujemy szybko oszacować wiele elementów, na przykład cały zakres kolejnego wydania.
Kiedy Planning Poker może nie być najlepszym wyborem? Gdy zespół już bardzo dobrze się zna i pracuje z podobnymi technologiami od lat, proces może być nadmiarowy dla prostych elementów. Ale nawet w takich zespołach, Planning Poker pozostaje wartościowy dla złożonych User Stories.
Narzędzia do Planning Poker — fizyczne vs cyfrowe
Wybór narzędzi do Planning Poker zależy od tego, czy zespół pracuje w jednej lokalizacji, czy rozproszony geograficznie.
Fizyczne karty Planning Poker
Nic nie zastąpi doświadczenia fizycznych kart, szczególnie dla nowych zespołów uczących się Scruma. Fizyczny gest wybierania karty i pokazywania jej w tym samym momencie tworzy wyjątkową dynamikę grupową. Karty można kupić gotowe lub wydrukować samodzielnie.
Aplikacje do Planning Poker online
Dla zespołów kolokowanyych i zdalnych dostępnych jest wiele aplikacji, a nawet dodatki w aplikacjach do wspierania pracy zdalnej. Najpopularniejsze to:
- PlanITPoker.com — prosta, darmowa aplikacja webowa
- Planning Poker Online — rozbudowane funkcje, integracja z Jira
- Scrum Poker Cards — aplikacja mobilna dla małych zespołów
- Zoom Apps — wtyczki Planning Poker bezpośrednio w Zoom
Ważne: narzędzie nie czyni Planning Poker skutecznym. To proces, facylitacja i kultura zespołu decydują o sukcesie.
Planning Poker w praktyce — case study z transformacji Agile
Pamiętam zespół z jednego z warszawskich banków, który przez miesiące walczył z nieprzewidywalnymi szacunkami. Sprint za Sprintem, ich velocity skakało jak na trampolinie — od 25 Story Points w jednym sprincie do 8 w następnym. Podczas pierwszego Sprint Planning, na którym byłem obecny, zauważyłem charakterystyczny wzorzec.
Zespół składał się z pięciu seniorów deweloperów i jednego juniora. Za każdym razem, gdy junior pokazywał kartę z wyższą wartością niż reszta zespołu, natychmiast się wycofywał: “Aha, to pewnie się mylę, może rzeczywiście to będzie 3 punkty”. Seniorzy kiwali głowami i przechodzili do następnego elementu.
Problem był fundamentalny — junior myślał o elementach Backlogu Produktu z perspektywy swojego doświadczenia, seniorzy z perspektywy swojego. Dla kogoś z dwuletnim stażem integracja z API rzeczywiście mogła zająć dwa dni. Dla seniora z dziesięcioletnim doświadczeniem — pół dnia. Żadne z tych szacunków nie było błędne, ale zespół marnował szansę na prawdziwą rozmowę o tym, kto będzie wykonywał dany element.
Wprowadziliśmy prostą zasadę: podczas dyskusji o różnicach w szacunkach, pierwsza wypowiada się osoba z najwyższym szacunkiem. To zmieniło dynamikę całego zespołu. Junior zaczął wyjaśniać swoje wątpliwości, seniorzy — dzielić się swoim doświadczeniem. Po trzech sprintach velocity zespołu ustabilizowało się na poziomie 18–22 Story Points i team zaczął systematycznie osiągać swoje cele sprintowe.
Planning Poker a Definition of Done
Często zapominamy, że szacowanie Story Points w Planning Poker musi być zgodne z Definition of Done zespołu. Jeśli DoD wymaga napisania testów jednostkowych, dokumentacji i code review, to wszystko to musi być uwzględnione w szacunku. Bez jasnej Definition of Done, Planning Poker staje się zgadywanką.
Dobry zespół przed rozpoczęciem Planning Poker przypomina sobie swoją Definition of Done i szacuje User Story zakładając, że wszystkie kryteria będą spełnione. To jedna z przyczyn, dlaczego Definition of Done jest tak istotna dla przewidywalności sprintów.
Planning Poker w erze zdalnej pracy
Transformacja do pracy zdalnej, przyspieszona przez pandemię, zmieniła również Planning Poker. Zespoły musiały szybko nauczyć się szacowania przez ekran, co na początku wydawało się wyzwaniem, chociaż niektóre z wymienionych powyżej narzędzi online istnieją od ponad dziesięciu lat.
Okazało się jednak, że Planning Poker online ma również swoje zalety. Narzędzia cyfrowe pozwalają na automatyczne zbieranie statystyk — zespół może analizować swoje wzorce szacowania, identyfikować obszary największych rozbieżności czy śledzić, jak poprawia się accuracy szacunków w czasie.
Niektóre zespoły eksperymentują z asynchronicznym Planning Poker — każdy członek zespołu może obejrzeć demo User Story, przemyśleć szacunek, a potem spotykają się synchronicznie tylko na dyskusję największych rozbieżności. To oszczędza czas, ale wymaga dojrzałości organizacyjnej.
Jeżeli jest problem z zakupem licencji na dedykowane narzędzie do Planing Poker online, to zawsze można poradzić sobie z tym wykorzystując mechanizm głosowania w Miro albo Muralu. Wystarczy stworzyć wirtualne karty przy każdym omawianym elemencie i uruchomić sesję głosowania.
Interesującą innowacją jest również “Planning Poker with AI assistance” — narzędzia, które analizują historyczne dane zespołu i sugerują prawdopodobne szacunki na podstawie podobieństwa do wcześniejszych elementów Backlogu Produktu. Nie zastępuje to ludzkiej oceny, ale może służyć jako dodatkowy punkt odniesienia.
Czy Planning Poker sprawdza się w każdym kontekście?
Planning Poker powstał w kontekście wytwarzania oprogramowania, ale jego zastosowanie rozszerzyło się na inne obszary. Widziałem zespoły marketingowe szacujące kampanie, zespoły HR oceniające złożoność procesów rekrutacyjnych, nawet teams produktowe szacujące wysiłek potrzebny na research użytkowników.
Kluczem do sukcesu Planning Poker poza IT jest adaptacja skali do specyfiki branży. Zamiast Story Points można szacować w dniach roboczych, poziomach złożoności komunikacyjnej czy nawet w “jednostkach kreatywności”. Ważne, żeby zespół wypracował wspólne rozumienie skali i konsekwentnie jej używał.
Jednak nie każdy kontekst nadaje się do Planning Poker. Tam, gdzie elementy Backlogu Produktu są bardzo podobne do siebie i powtarzalne, tradycyjne szacowanie bazujące na historycznych danych może być skuteczniejsze. Planning Poker błyszczy w środowiskach o wysokiej niepewności i złożoności — dokładnie tam, gdzie Scrum sprawdza się najlepiej.
Planning Poker jako element kultury zwinności
Prawdziwa wartość Planning Poker wykracza poza sam proces szacowania. To narzędzie budowania kultury transparentności, współpracy i ciągłego uczenia się. Zespoły, które dobrze opanowały Planning Poker, zwykle lepiej radzą sobie też z innymi praktykami Scrum.
Dlaczego? Bo Planning Poker uczy fundamentalnych kompetencji zwinnego zespołu: słuchania różnych perspektyw, konstruktywnej dyskusji o niepewności, podejmowania decyzji grupowych i uczenia się z różnic w rozumowaniu. To wszystko przyda się podczas Retrospekcji Sprintu, Daily Scrum czy codziennego rozwiązywania problemów.
W tym kontekście Planning Poker przestaje być techniką szacowania, a staje się ćwiczeniem w byciu prawdziwie zwinnym zespołem. I może właśnie dlatego, mimo dostępności wielu alternatyw, pozostaje tak popularne wśród praktyków Scrum na całym świecie.
Planning Poker to znacznie więcej niż sposób na przypisywanie liczb do elementów Backlogu Produktu. To filozofia podchodzenia do niepewności z pokorą, ale też z metodą. W świecie, gdzie jedyną pewną rzeczą jest zmiana, umiejętność kolektywnego myślenia o przyszłości staje się kluczową kompetencją każdego zespołu. Planning Poker oferuje prostą, ale skuteczną metodę jej rozwijania.
Planning Poker — najczęściej zadawane pytania (FAQ)
Czym dokładnie jest Planning Poker?
Planning Poker to oparta na konsensusie, zgamifikowana technika używana przez Zespoły Agile do szacowania wielkości i złożoności elementów Backlogu Produktu. Jej głównym celem jest doprowadzenie do wspólnego zrozumienia elementu poprzez dyskusję, co czyni ją idealnym narzędziem na sesje Product Backlog Refinement.
