Team Estimation Game to technika estymacji używana podczas Sprint Planningu w Scrum. Czym różni się od Planning Pokera? Dlaczego niektóre Zespoły Developerskie uważają ją za bardziej efektywne narzędzie? O tym przeczytacie w poniższym artykule.

Team Estimation Game – omówione zagadnienia:

  1. Wprowadzenie
  2. Zasady Team Estimation Game
  3. Team Estimation Game a Planning Poker
  4. Podsumowanie

Wprowadzenie

Team Estimation Game nazywana jest również Swimlanes Estimation. To drugie określenie zostało ukute spontanicznie, a wzięło się z obserwacji ułożonych na stole kart do estymacji, które wyglądają właśnie jak tory pływackie w sportowym basenie.

Team Estimation Game nieustannie zyskuje na popularności, ponieważ Zespoły Developerskie tworzą estymacje z jej użyciem mniej więcej 3 razy szybciej niż używając Planning Pokera, o którym pisaliśmy w poprzednim artykule [link]. Na czym więc polega Team Estimation Game?

Zasady Team Estimation Game

Akcesoria potrzebne do gry w Team Estimation Game to:

  • talia kart z User Stories – przygotowywana osobno do każdej rozgrywki
  • talia kart z wartościami punktowymi – mogą być używane wielokrotnie

Karty z User Stories powinny być na początku ułożone w stos, w kolejności odpowiadającej wpisom do Backlogu Produktu. Dzięki temu w pierwszej kolejności zostaną oszacowane te, których wykonanie jest najpilniejsze.Karty z punktami zazwyczaj zawierają wartości odpowiadającemu ciągowi Fibonacciego. Jest to sekwencja następujących liczb: 0, 1, 3, 5, 8, 13, 20, 40 i 100. Mogą być także oznaczone kolejnymi potęgami liczby 2, czyli 2, 4, 8, 16, 32, i tak dalej.

Aby zagrać w Team Estimation Game, członkowie Scrum Team siadają dookoła stołu. Przebieg gry wygląda następująco:

  1. Grę rozpoczyna Product Owner. Wyciąga on pierwszą kartę z talii User Story. Opowiada o jej zawartości, po czym kładzie ją na stole.

    Wyjaśnia pozostałym członkom Scrum Team, że po lewej stronie karty należy umieszczać User Story łatwiejsze, a po prawej – trudniejsze do realizacji. Jeśli któreś z nich mają taki sam stopień trudności, zostają umieszczone jedna pod drugą, poniżej karty znajdującej się na stole.

    Kolejny ruch wykonuje osoba siedząca obok, zgodnie z ruchem wskazówek zegara.

  2. Osoba wyciąga kartę z talii User Story. Czyta jej treść, która jest następnie objaśniana przez Product Ownera. Osoba trzymająca kartę kładzie ją następnie na stole wybierając miejsce zgodnie z własnym zdaniem na temat trudności tej User Story. Następnie uzasadnia swój wybór, a pozostali członkowie Scrum Team mogą zadawać jej pytania. Nie mogą jednak kwestionować jej decyzji.
  3. Każda następna osoba ma do wyboru dwa ruchy:
    • powtórzyć punkt 2
    • przesunąć jedną z kart leżących na stole w miejsce, które uzna za najwłaściwsze

    W przypadku wyboru drugiej opcji, należy również uzasadnić decyzję o zmianie estymacji.

    Krok trzeci jest powtarzany aż do momentu wyczerpania talii z User Stories.

  4. Końcowy etap rozmieszczania kart z User Stories to jedna – lub kilka, w zależności od praktyki przyjętej przez Scrum Team – runda, w której każdy z graczy ma możliwość przesunięcia jednej z kart na stole w odpowiedniejsze miejsce.
  5. Dopiero gdy wszystkie karty z User Stories mają już swoje finalne miejsca, Zespół Developerski przechodzi do przypisania ilości Story Points. Nad każdym z pasów zostaje umieszczona karta z liczbą punktów. Pierwszej karcie z lewej Product Owner przyporządkowuje kartę z najmniejszą liczbę punktów. Natomiast zasada rozmieszczania kolejnych jest analogiczna do punktów 3 i 4.

    W ten sposób estymacja zostaje zakończona.

Team Estimation Game

Team Estimation Game a Planning Poker

Team Estimation Game jest zwykle bardziej efektywnym narzędziem estymacji niż Planning Poker. Dzieje się tak, z powodu następujących różnic pomiędzy tymi technikami.

  • Karta-stół. W Team Estimation game obowiązuje znana z popularnych gier karcianych „zasada karta-stół”. Oznacza ona, że nie można cofnąć raz położonej karty. Dzięki temu, że User Story szacowana jest przez jedną osobę równocześnie wahanie się pomiędzy szacunkami i liczba ich zmian jest znacząco ograniczona w stosunku do Planning Pokera.
  • Wystarczająco trafna estymacja. W Planning Pokerze przy każdej User Story powinien zostać osiągnięty pełny konsensus. Natomiast w Team Estimation Game decyzję podejmuje jedna osoba. Nawet jeśli jej estymacja jest nietrafna, z dużym prawdopodobieństwem zostanie skorygowana przez innego Developera. W ten sposób zwykle znacznie szybciej zostaje podana wystarczająco trafna estymacja.
  • Wystarczająco długa dyskusja. Dyskusje często nadmiernie się wydłużają podczas gry w Planning Pokera. Ich czas znacznie się skraca podczas Team Estimation Game, ponieważ koncentrują się na decyzji podjętej przez jednego z Developerów, a nie na charakterze każdej User Story.

Jedną z potencjalnych wad Team Estimation Game jest poczucie niesprawiedliwości. Jeśli Zespół Developerski jest liczniejszy niż ilość User Stories przewidzianych do realizacji w danym Sprincie, niektórzy Developerzy mogą czuć się pominięci.

Podsumowanie

Team Estimation Game jest najbardziej efektywną techniką estymacji dla większości Scrum Teams. Należy jednak pamiętać, że jest to tylko narzędzie służące do szacowania trudności i pracochłonności User Stories. I jak każde narzędzie powinno być dostosowane do potrzeb i możliwości członków Zespołu.

Sprawdź kolejny pis z serii Przewodnik Scrum: Czym jest Przyrost w Scrum?

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

Scrum Guide | 25. Team Estimation Game jako alternatywa dla Planning Pokera 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?