Planning Poker jest jedną z technik estymacji używanych w Scrum. Rozgrywa się go podczas Sprint Planningu. Graczami są członkowie Zespołu Developerskiego. Każdy z nich równocześnie wykłada na stół kartę z ilością Story Points, na jaką szacuje opisane przez Product Ownera zadanie. Jakie są zalety i wady Planning Pokera?

Planning Poker – omówione zagadnienia:

  1. Wprowadzenie
  2. Jak grać w Planning Pokera?
  3. Zalety i wady Planning Pokera
  4. Podsumowanie

Wprowadzenie

Planning Poker, nazywany także Scrum Poker albo Pointing Poker to relatywna technika szacowania ilości pracy potrzebnej do wykonania konkretnego zadania. Stworzył ją w 2022 roku James Grenning. Chciał w ten sposób rozwiązać problem niekończących się sporów w Scrum Team dotyczących oceny trudności zadań stawianych przed Developerami.

Jak grać w Planning Pokera?

Celem Planning Pokera jest estymacja trudności i pracochłonności każdej z User Stories wybranych do wykonania w danym Sprincie. Zasady gry w Planning Pokera są proste. Najpierw należy jednak przygotować niezbędne akcesoria.

Akcesoria do gry

Akcesoria do gry w Planning Pokera to:

  • jedna talia kart z User Stories – przygotowywana osobno do każdej rozgrywki
  • talie kart z wartościami punktowymi – po jednej talii dla każdego z Developerów, używane wielokrotnie

Karty z punktami zazwyczaj zawierają wartości odpowiadającemu ciągowi Fibonacciego, czyli sekwencję 0, 1, 3, 5, 8, 13, 20, 40 i 100. Zdarza się również, że są oznaczone kolejnymi potęgami liczby 2, czyli 2, 4, 8, 16, 32, i tak dalej. Dlaczego nie są to kolejne liczby? Ponieważ w Planning Poker chodzi o wyraźne pokazanie różnic pomiędzy trudnością wykonywanych zadań. Zaś zbyt małe różnice pomiędzy wartością kart zaciemniały by obraz estymacji.

Liczby zwykle wyrażają ilość Story Points. Mogą to być jednak także inne jednostki miary używane przez Scrum Team. Więcej na temat jednostek estymacji i Story Points napisaliśmy w tym artykule.

Zasady Planning Pokera

Fazy przebiegu:

  1. Przedstawienie User Story
  2. Dyskusja
  3. Rozgrywka (Fazy 2. oraz 3. są powtarzane aż do momentu osiągnięcia konsensusu)
  4. Konsensus
  5. Przejście do kolejnej User Story

Gra w Planning Pokera ma miejsce podczas Sprint Planningu. Product Owner trzyma w ręce karty User Stories. Natomiast każdy z Developerów otrzymuje talię kart z punktami.

Moderatorem jest Product Owner. Rozpoczyna on grę od przedstawienia jednej User Story pozostałym członkom Scrum Team. Jeśli pojawiają się pytania, powinny zostać zadane od razu po przedstawieniu User Story.

Kolejnym krokiem jest rozpoczęcie dyskusji na temat realizacji User Story. W rozmowie bierze udział cały Scrum Team, jednak głównymi uczestnikami są Developerzy. Dyskusja dotyczy między innymi zagadnień takich jak:

  • techniczna strona wykonania zadania
  • umiejętności poszczególnych Developerów, które będą niezbędne do jego realizacji
  • sposobów radzenia sobie ze spodziewanymi trudnościami
  • dodatkowych zadań wiążących się z realizacją User Story.

Gdy Developerzy ustalą odpowiedzi na najważniejsze pytania, każdy z nich samodzielnie wybiera jedną z kart ze swojej talii. Kładzie na stół kartę, której wartość jego zdaniem najlepiej odzwierciedla stopień skomplikowania User Story.

Kolejny krok zależy od tego, jakie karty zostały wyłożone.

  • Jeśli Developerzy położyli na stole karty o różnych wartościach, wracają do dyskusji.A następnie zabierają ze stołu karty i ponownie szacują wartość User Story. Sytuacja się powtarza, a Developerzy wykładają karty ponownie aż do uzyskania konsensusu.
  • Jeśli Developerzy zgodnie ocenili User Story, przechodzą do kolejnej tury Planning Pokera.Product Owner prezentuje kolejną User Story i procedura powtarza się aż do wyczerpania puli User Stories planowanych do realizacji w bieżącym Sprincie.
Scrum technique: Planning Poker

Zalety i wady Planning Pokera

Zaletą Planning Pokera jest bez wątpienia ustandaryzowanie pracy z User Stories. Zespół Developerski trzyma w ręce gotowy zestaw kart służący do szacowania ilości pracy. Dzięki temu w każdym Sprincie wartości pozostają niezmienne, a Zespół uczy się estymacji w określonych jednostkach.

Ważną zaletą jest także równy udział wszystkich Developerów w szacowaniu skomplikowania zadania. Nawet osoby, które nie biorą bezpośrednio udziału w jego wykonaniu mogą wnieść istotny wkład w dyskusję. Na przykład zwracając uwagę na problemy, które nie przyszły do głowy Developerom nastawionym na techniczne aspekty wykonania zadania.

Kolejną korzyścią płynącą z wykorzystania tego narzędzia jest możliwość ustawienia limitów czasowych na dyskusję, a także – w razie potrzeby – ograniczenia ilości rund rozgrywanych do każdej User Story.

Czas potrzebny do osiągnięcia konsensusu jest jednak także jedną z najczęściej wymienianych wad Planning Pokera. Jeśli jeden lub kilku Developerów nie chce zgodzić się z estymacją pozostałych, gra może potencjalnie ciągnąć się w nieskończoność.

Podsumowanie

Planning Poker jest bardzo efektywną techniką relatywnej estymacji. Zespół Developerski otrzymuje gotowe ramy działania i wartości punktowe służące do szacowania czasu i trudności wykonywanych zadań. Dzięki temu może skoncentrować się na dyskusji nad rozwiązywaniem problemów. A także doskonalić swoje estymacje porównując szacowany i realny czas realizacji User Stories.

Sprawdź również inne metody planowania w Scrum: Team Estimation Game

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 24. Jak działa Planning Poker? caroline becker avatar 1background

Autor: Karolina Berecka

Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?