Na czym polega Planning Poker?

Planning Poker, określany też przez wielu jako Scrum Poker, to bardzo popularna wśród zespołów Scrumowych praktyka estymowania elementów Backlogu Produktu. Została spopularyzowana za sprawą książki Mike’a Cohna „Agile Estimating and Plannnig”. Po raz pierwszy opisał ją jednak w swojej publikacji James Grenning.

Ojciec Planning Pokera wpadł na ten pomysł w trakcie facylitacji jednego ze spotkań swojego zespołu. Było ono o tyle niewdzięczne, że zostało całkowicie zdominowane przez dwóch developerów, podczas gdy reszta jego uczestników zaczęła przysypiać. Grenning stanął więc przed niełatwym wyzwaniem przywrócenia dyskusji na właściwe tory i zaangażowania wszystkich zgromadzonych.

Jak zapewne się domyślasz, Scrum Poker, poza faktem używania kart, nie ma wiele wspólnego z grą o tej samej nazwie. Jak zatem „grać” aby szacowanie było efektywne i pomogło zespołowi zaplanować nadchodzący Sprint?

Jak przebiega sesja Planning Pokera?

Każda sesja szacowania relatywnego przy użyciu Planning Pokera wygląda w zasadzie bardzo podobnie, a reguły gry nie są skomplikowane. Składa się z następujących kroków.

Wybór User Stories

Pierwszym krokiem jest wybranie i przygotowanie elementów Product Backlogu, które będą poddane dyskusji na sesji Scrum Pokera. Najczęściej są one spisywane w formule User Stories. Dobrą praktyką jest rozesłanie ich do zespołu przed spotkaniem, celem wcześniejszego zaznajomienia się.

Komentarz Product Ownera i dyskusja

Product Owner rozpoczyna sesję od dokładnego opowiedzenia danej Historyjki Użytkownika czy zadania z Backlogu Produktu. Następnie cały zespół rozpoczyna dyskusję. Może zadawać pytania uszczegóławiające, aby lepiej zrozumieć co jest do wykonania w ramach danej historyjki i jaką reprezentuje ona wartość.
Dobrze gdy Developerzy w tym miejscu podzielą się również pewnymi ograniczeniami technicznymi czy problemami, jakie potencjalnie mogą wystąpić w toku realizacji.

Pierwsza runda estymacji Planning Pokera

Gdy temat się wyczerpie i wszystkie wątpliwości zostaną rozwiane, rozpoczyna się pierwsza runda estymacji. Na tym etapie każdy członek zespołu dobiera indywidualnie ze swojej talii kart, taką która odpowiada jego subiektywnej ocenie, ale póki co jeszcze jej nie ujawnia. Wartość na karcie najczęściej jest wyrażona w abstrakcyjnej jednostce jaką są Story Pointy, a nie w godzinach czy tak zwanych man daysach.

Czym są Story Pointy?

W talii graczy dostępne są karty reprezentujące uproszczony ciąg liczb Fibonacciego. Pierwsza z nich to 1, następna 2, a każda kolejna to suma dwóch poprzednich czyli 3, 5, 8, 13 itd. Czasami, w niektórych wersjach kart do Planning Pokera, karty większe niż 13 upraszczają tę zasadę i po prostu dublują poprzednią wartość – 20, 40, 80.

Wbrew powszechnej opinii, Story Pointy wyrażają nie tylko złożoność danej historyjki użytkownika, ale również ryzyko z nią związane i ogólną pracochłonność. Można zatem powiedzieć że jednostka ta reprezentuje ogólny wysiłek jaki trzeba włożyć, aby ukończyć konkretne User Story zgodnie z Definition of Done. Więcej o samych Story Pointach już wkrótce w kolejnym artykule na blogu.

W Scrum Pokerze mamy do czynienia z tak zwanym szacowaniem relatywnym, czyli bazującym na relacjach, porównaniach. Porównujemy ze sobą nowe Historyjki Użytkownika z tymi już zrealizowanymi w przeszłości. Innymi słowy jeżeli nowa User Story jest estymowana na 5 punktów, oznacza to, że pod kątem wspomnianego wysiłku jest podobna do innych historyjek z przeszłości o tej samej wartości. Jednocześnie możemy powiedzieć że jest „większa” niż te o wartości 3 punktów i „mniejsza” niż te oszacowane na 8.

Odkrycie kart i kolejna dyskusja

Gdy wszyscy członkowie zespołu są już gotowi ze swoimi estymatami, na znak facylitatora odkrywają karty. Kolejnym krokiem jest poszukiwanie wartości skrajnych i ponowne rozpoczęcie dyskusji. Zaczyna ją osoba, która daną historyjkę użytkownika oszacowała najniżej lub najwyżej. To kluczowy moment warsztatu Planning Poker.

Być może najbardziej optymistyczna ocena była spowodowana tym, że istnieje jakieś proste rozwiązanie, nieznane reszcie zespołu? A może estymowana właśnie historyjka jest obarczona bardzo dużym ryzykiem, którego była świadoma tylko osoba estymująca najwyżej? Co jest powodem takiej, a nie innej wartości? Wszelkie tego typu komentarze i odpowiedzi powinny wybrzmieć właśnie teraz rozpoczynając szczegółową dyskusję nad historyjką.

Kolejna runda estymacji Planning Pokera

Gdy wątpliwości zostaną rozwiane, a Product Owner odpowie na wszystkie pojawiające się pytania, zespół może przejść do kolejnej tury szacowania. Wygląda ona identycznie jak pierwsza, czyli każdy indywidualnie przygotowuje swoją kartę, którą obróci na znak facylitatora. Na tym etapie wartości powinny być już nieco bardziej zbliżone do siebie. Czynność powtarzamy do momentu, w którym członkowie zespołu osiągną consensus co do konkretnej wartości omawianej historyjki użytkownika.

Korzyści z używania Scrum Pokera

Wbrew powszechnej opinii to nie sam proces przypisania do historyjki konkretnej wartości w Story Pointach jest tutaj kluczowy. Oczywiście posiadanie estymat pomoże później w wyznaczeniu średniej prędkości twojego zespołu (velococity). Jej znajomość będzie z kolei przydatna na Planowaniu Sprintu i odpowiedzeniu na pytanie ile realnie Developerzy są w stanie zrealizować w nadchodzącej iteracji.

Nie mnie jednak to sama dyskusja zespołu o tym, co będzie do zrobienia, stanowi jedną z największych korzyści sesji Plannig Pokera. Pogłębianie treści Historyjki Użytkownika, zadawanie pytań uszczegóławiających czy też zderzanie ze sobą różnych punktów widzenia poprawia kompleksowo zrozumienie zakresu jej prac. To z kolei powoduje ograniczenie ryzyka tego, że zrealizujemy nie to czego oczekiwał Product Owner i interesariusze.

A zatem jeżeli Developerom w twoim zespole zależy wyłącznie na jak najszybszym powpisywaniu Story Pointów w odpowiednim polu w Jirze, bo tak kazał Scrum Master, to wiedz, że coś się dzieje 😉

Wady sesji Planning Pokerowych

Holistyczna i dogłębna analiza treści historyjek użytkownika ma też niewątpliwie swoje wady. Pierwszą jaka przychodzi mi do głowy to raczej niska efektywność tego procesu. Byłem świadkiem wielu sesji, w których przez godzinę udało się oszacować zaledwie dwie czy trzy user story. Oczywiście nie musi się tak dziać za każdym razem. Nie mniej jednak prędzej czy później doświadczycie takiego Planning Pokera, w którym efekt w porównaniu do włożonego wysiłku, będzie znikomy.

Planning Poker ma też niestety tę przypadłość, że jest to dosyć wyczerpująca praktyka. Historyjka, za historyjką, pytanie za pytaniem, estymata za estymatą… Do tego nierzadko zmiana kontekstu. Uwierzcie mi, nawet najbardziej zaprawionym w boju Developerom może się od tego wszystkiego zagotować mózg 🙂 Nie bez przyczyny zresztą każdy w swojej talii ma też kartę z symbolem kawy lub czaszki, która oznacza prośbę o natychmiastową przerwę w grze.

Najczęstsze błędy przy Planning Pokerowe rozgrywce

Sprawne korzystanie z Planning Pokera wymaga oczywiście wprawy, która wyrobi się wśród członków zespołu z czasem. Początki, jak to zwykle bywa, mogą być trudne, ale postaraj się za wszelką cenę wystrzegać poniższych błędów.

Wybieganie przed szereg

Często Developerzy mają tendencję do obwieszczania na głos proponowanej przez siebie estymaty, psując tym samym efekt zaskoczenia przy odkryciu kart na koniec rundy. Powoduje to tak zwany efekt zakotwiczenia. Jeżeli ktoś powie głośno: „dla mnie to będzie taka ósemka”, to poprzez taką sugestię nakierowuje myślenie pozostałych członków zespołu na tę właśnie wartość. Trudniej będzie się już od niej uwolnić, nawet jeżeli chcieliśmy zagrać inną kartę, gdyż podświadomie nasz mózg już przetwarza ósemkę. Dlatego właśnie tak ważne dla porównania ze sobą różnych punktów widzenia jest estymowanie w ciszy, a dopiero potem dyskusja dlaczego zdecydowaliśmy się na taką, a nie inną wartość.

Za długie sesje na raz

Jak już wspominałem wcześniej, Planning Poker jest praktyką pochłaniającą dużo energii. Nie sposób utrzymać wysoki poziom zaangażowania i skupienia Developerów przez wiele godzin. Im dłużej trwa warsztat, tym mocniej będzie ono spadać, a mózgi członków naszego zespołu zaczną szukać dróg na skróty zamiast kompleksowo analizować historyjki. Nie jest zatem zbyt dobrym pomysłem poświęcanie połowy dnia na Scrum Pokera, gdyż po prostu będzie to nieefektywne. Lepiej „grać” częściej, ale w mniejszych dawkach.

Estymowanie odległych elementów Backlogu

Bardzo często Product Ownerzy wpadają na pomysł, żeby oszacować historyjki na kilka miesięcy w przód i „będzie spokój„. Dlaczego nie jest to dobre podejście?
Po pierwsze będzie to wymagało długich i męczących posiedzeń przy Scrum Pokerze, o konsekwencjach których pisałem wyżej.

Po drugie, postępując zgodnie z zasadami Agile’a, zakładamy przecież, że odległa przyszłość jest niepewna. Stosujemy metodę małych kroków, ograniczając tym samym ryzyko minięcia się z aktualnymi potrzebami naszych użytkowników końcowych. A zatem oszacowanie według naszej dzisiejszej wiedzy elementów Backlogu, którymi zajmiemy się za pół roku jest marnotrawstwem. Daje nam tylko bardzo złudne poczucie, że jesteśmy w stanie zapanować nad przyszłością i dokładnie ją zaplanować. Przy tworzeniu skomplikowanych, złożonych produktów, w dynamicznym, szybko zmieniającym się środowisku, jest to po prostu niemożliwe.

Niskiej jakości skala referencyjna lub jej brak

Z czasem, gdy zespół agile’owy doświadczy już kilka sesji Planning Pokera, będzie miał swoją skalę referencyjną w głowie. Błędem jest jednak nie stosowanie jej od początku, chociażby w uproszczonej formie. Nie zapominajmy, że stosujemy tutaj metodę szacowania relatywnego, polegającą na porównywaniu ze sobą elementów. Przykładowe 5 Story Pointów, w oderwaniu od skali referencyjnej znaczy tyle co nic. Dopiero porównanie historyjki do innych w tej kategorii i zestawienie z mniej pracochłonnymi trójkami i bardziej pracochłonnymi ósemkami przybliża nas do poznania rzeczywistości. Warto zatem zbudować sobie prostą skalę, w której znajdziemy reprezentanta każdej z wartości, co ułatwi późniejsze porównywanie.

Narzędzie do zdalnego Planning Pokera

W dobie pracy zdalnej, fizyczne karty do Scrum Pokera trzeba było zastąpić czymś innym. Dobra wiadomość jest taka, że do zdalnej sesji nie potrzebujecie żadnych specjalistycznych, a tym bardziej płatnych narzędzi. Otóż wystarczy, że włączycie kamerki i na sygnał od facylitatora będziecie pokazywać na palcach swoje estymaty 🙂 Oczywiście dla wartości powyżej 8, trzeba się umówić na konkretne symbole z użyciem obu rąk. Jeżeli macie gdzieś karty fizyczne, możecie też po prostu pokazywać je do kamery.

Jeżeli jednak z jakiegoś powodu nie jest możliwe, aby wszyscy Developerzy uruchamiali kamerki, albo potrzebujecie nieco bardziej zaawansowanych funkcji, możecie skorzystać z bardzo prostego i darmowego narzędzia planITpoker. Posiada ono wiele dodatkowych funkcjonalności. Przykładowo wprowadzanie historyjek użytkownika użytkownika, wyciąganie średnich z estymat, ustawienie opcji automatycznego odkrycia kart po głosowaniu, timer i wiele innych.

A Wy jakie macie doświadczenie ze stosowaniem tej praktyki? Czy popełnialiście wymienionej wyżej błędy? Zachęcam do pozostawienia komentarza poniżej 🙂