AgileAdept.pl
planning poker agile

Jeśli nie Planning Poker to co?

Plannnig Poker to bardzo popularna wśród zespołów agile’owych praktyka estymowania elementów Backlogu Produktu. Szczególnie upodobały ją sobie te działające zgodnie z frameworkiem Scrum, które określają ją nawet jako Scrum Poker. Nie jest to jednak metoda pozbawiona wad o czy wspominam szerzej w artykule Na czym polega Planning Poker?.

Jedną z nich jest chociażby to, że będzie trudna w zastosowaniu, jeżeli nie posiadamy na start odpowiedniej skali referencyjnej. Przy szacowaniu relatywnym, z którego korzysta się grając w Planning Pokera, niezbędne jest porównywanie ze sobą nowych elementów do tych już ukończonych (zgodnie z Definition of Done). Nie będzie to zatem możliwe w zespołach, które dopiero rozpoczynają wspólną pracę nad produktem i mają niewielkie doświadczenie w stosowaniu agile’a w praktyce. Wówczas będziemy korzystać z tak zwanej metody szacowania LWPZD, czyli Liczb Wyciągniętych Prosto Z D… dziupli 😉
Z pomocą przychodzi nam alternatywna metoda czyli Team Estimation Game.

planning poker karty

Team Estimation Game alternatywą Planning Pokera

Team Estimation Game jest nieco prostszą w swych założeniach metodą szacowania elementów Backlogu Produktu, takich jak przykładowo User Story. Tak samo jak Planning Poker opiera się na estymowaniu relatywnym, czyli porównywaniu między sobą danych elementów, ale w początkowej fazie nie wymagana jest żadna skala referencyjna czy też abstrakcyjne Story Pointy.

Nie będą też potrzebne żadne dodatkowe karty czy aplikacje jak w przypadku Planning Pokera. Wystarczą jedynie przygotowane wcześniej elementy Backlogu, które chcemy oszacować, trochę miejsca na stole w salce konferencyjnej lub, w wersji online, pusta tablica w Miro czy Muralu.

planning poker alternatywa
Team Estimation Game

Jak grać w Team Estimation Game?

  1. Przygotuj karty z wydrukowanymi User Stories i ułóż je na stosie w takiej kolejności, w jakiej występują w Backlogu Produktu. Alternatywnie w wersji online mogą to być oczywiście wirtualne karteczki na tablicy Miro/Mural.
  2. Umieść pierwszą kartę na stole i przeczytaj na głos jej treść. Następnie poinstruuj zespół po której stronie mają być kładzione bardziej pracochłonne Historyjki Użytkownika, a po której mniej. Im dalej w prawo, tym trudniejsze.
  3. Osoba, która rozpoczyna grę, wyciąga kolejną kartę ze stosu, czyta ją i kładzie obok pierwszej (po lewej lub prawej stronie) decydując tym samym czy dany element Backlogu jest jego/jej zdaniem bardziej lub mniej pracochłonny. Swoją decyzję argumentuje na głos.
  4. Kolejny uczestnik powtarza tę czynność, dobierając następną kartą ze stosu lub przesuwa karty, które już znajdują się na stole. Ma do dyspozycji tylko jeden ruch.
    Jeżeli zdaniem członka zespołu kilka Historyjek Użytkownika jest mniej więcej tego samego rozmiaru, należy je ułożyć w pionie, jedna nad drugą.
  5. Gra toczy się, aż wszystkie User Story lub inne elementy Backlogu przygotowane na sesję, zostaną w ten sposób oszacowane i rozłożone.
  6. Każda czynność musi być uzasadniona. Gracze są zobowiązani do komentowania swoich decyzji i dzielenia się wszelkimi spostrzeżeniami, doświadczeniem i wiedzą. Wpływa to bardzo pozytywnie na ogólno-zespołowe zrozumienie tego co jest de facto do wykonania w ramach estymowanych elementów Backlogu. Na warsztacie powinien być także obecny Product Owner, który może na bieżąco odpowiadać na pytania i rozwiewać wątpliwości Deweloperów.
  7. Gdy wszystkie karty ze stosu zostaną rozłożone na stole, należy zrobić jeszcze jedną, pełną rundę na ewentualne przesunięcia i zmiany. Jeżeli dany element Backlogu zmienia swoją pozycję więcej niż 3-4 razy to znak, że należy go przeanalizować bardziej szczegółowo. Prawdopodobnie jest jeszcze nie do końca zrozumiały przez Developerów i wymaga doprecyzowania.
  8. Następnie zespół tworzy “kategorie pracochłonności” poprzez przypisanie konkretnym grupom Historyjek Użytkownika w danym obszarze “na osi” wartości liczbowych zaczerpniętych z ciągu Fibonacciego (analogicznie jak Planning Poker). Może też do tego celu wykorzystać dowolną, inną skalę, niekoniecznie Story Pointy.
    Często zespoły korzystają z odzieżowej nomenklatury i tworzą kategorie XS, S, M, L, XL, XXL. Pracowałem też z Zespołami Scrumowymi, które poszczególne grupy historyjek opisywały wielkościami owoców – malina, kiwi, pomarańcza, kokos, arbuz. Na tym etapie powinno to wyglądać mniej więcej tak jak na obrazku poniżej. Żółte karteczki to pojedyncze User Stories.

Ostatnim krokiem jest ponowne przejrzenie wszystkich oszacowanych historyjek i dokonanie ewentualnych, finalnych przesunięć pomiędzy poszczególnymi kategoriami.
Warto w tym momencie dodać, że historyjki estymowane na przykładowo 8 Story Pointów nie muszą być identyczne pod kątem pracochłonności. Chodzi o to, że są za duże, aby zmieścić się razem z innymi “piątkami” i za małe aby przypisać je do “trzynastek”. Takie porównywanie to właśnie esencja szacowania relatywnego.

Pamiętajcie, empiryczne podejście agile zakłada, że nie istnieją jedyne słuszne, zawsze działające, najlepsze praktyki, które możemy po prostu bezmyślnie skopiować do swojego zespołu. Najlepsze są te, które opracujemy sami, dostosowując do naszego kontekstu i potrzeb. Zachęcam Was zatem do ciągłego eksperymentowania i wyciągania wniosków :).

Przewaga Team Estimation Game nad Planning Pokerem

Po pierwsze, szacowanie oparte na prostym porównywaniu, początkowo bez stosowania abstrakcyjnych Story Pointów, jest łatwiejsze do zrozumienia i zastosowania od zaraz. Team Estimation Game będzie szczególnie przydatne w dopiero co powstałych zespołach agile, które nie posiadają jeszcze swojej referencyjnej skali Historyjek Użytkownika i dopiero będą ją tworzyć.
Unikamy też dzięki temu antywzorca jakim jest przeliczanie Story Pointów na godziny, ponieważ Deweloperzy nie muszą od razu, z marszu, odpowiadać na pytanie “ile to będzie?”. Porównują po prostu ze sobą pracochłonność poszczególnych User Stories.

Po drugie, w czasie trwania jednej sesji estymacyjnej każda Historyjka Użytkownika będzie oceniana kilkukrotnie. Zasady gry mówią, że nowe Historyjki muszą być cały czas porównywane z tymi, które zostały już oszacowane i leżą na stole. Dzięki temu estymacje powinny być bardziej precyzyjne i holistyczne. W Planning Pokerze każda User Story, po przypisaniu do niej danej wartości w Story Pointach, zazwyczaj nie jest już ponownie omawiana.

Po trzecie w ramach jednej sesji Team Estimation Game możemy oszacować dużo większą liczbę elementów niż przy czasochłonnym Planning Pokerze. Formuła tego warsztatu jest dużo szybsza, co pozwala zaoszczędzić sporo czasu, nie tracąc jednocześnie na jakości estymat i nie gubiąc całościowego obrazka.

Po czwarte, nie mniej istotne, gra jest bardziej przyjazna introwertykom, których nie brakuje śród developerów. Pozwala bowiem każdej osobie wyrazić i uzasadnić swoją opinię, bez potrzeby przekrzykiwania innych, bardziej wygadanych członków zespołu. Każdy ma swoją rundę, swój czas na decyzję i komentarz.

A Wy z jakiej metody korzystacie szacując elementy Backlogu? Jakie macie doświadczenia z Planning Pokerem i Team Estimation Game? Zachęcam do pozostawienia komentarza poniżej.

Jarek Łojko

Dodaj komentarz

AgileAdept.pl