Skip to content

Team Estimation Game jako alternatywa dla Planning Pokera

W jednym z poprzednich wpisów spróbowałem wytłumaczyć, na czym polega relatywne szacowanie w story pointach. Istnieje wiele technik, które to wspierają, a chyba najpopularniejszą jest Planning Poker. Jest to świetna technika, jednak ma kilka słabszych punktów:

  • Ile? Deweloperzy próbują od razu odpowiedzieć na pytanie „ile?” zamiast porównywać ze sobą różne elementy Backlogu Produktu (np. historyjki użytkownika) i określać relatywny rozmiar.
  • Powrót do szacowania w jednostkach czasu. Odpowiadając na pytanie „ile?” deweloperzy szukają jakiegoś odniesienia dla „abstrakcyjnego” story pointa i znajdują go znowu w godzinach albo dniach.
  • Szacowanie zajmuje dużo czasu, a gra na dłuższą metę jest nudna i męcząca. Zabawnie jest chyba tylko pierwsze dwa razy.
  • To 2 czy 3 punkty? Często prowadzi do przedłużających się dyskusji o nieistotne szczegóły zamiast budować wspólne rozumienie wymagań.
  • Falstarty. Co niecierpliwsi nagminnie odkrywają karty zanim koledzy z zespołu wybiorą swoje.

W zespołach, z którymi pracuję, jako alternatywę dla Planning Pokera jakiś czas temu zaczęliśmy wykorzystywać technikę Team Estimation Game.

Team Estimation Game — przebieg gry

  1. Przynosimy przygotowany wcześniej stos kart z historyjkami użytkownika. Najlepiej, jeśli karty będą ułożone zgodnie z kolejnością w Backlogu Produktu, czyli na górze stosu będzie historyjka z góry Backlogu.
  2. Wykładamy pierwszą kartę ze stosu na środek stołu.
  3. Ustalamy, po której stronie tej karty mają leżeć karty większe, a po której mniejsze.
  4. Pierwsza osoba zdejmuje ze stosu kolejną kartę i, w zależności czy uzna ją za większą lub mniejszą, kładzie ją po odpowiedniej stronie już leżącej karty. Jeśli uzna, że obie karty mają zbliżony rozmiar, to układa je razem w pionową kolumnę.
  5. Następna osoba ma dwie opcje:
    1. zdjąć kolejną kartę ze stosu i ułożyć ją w odpowiednim miejscu względem leżących już na stole lub
    2. przesunąć jedną (ale tylko jedną) z już ułożonych na stole kart w inne miejsce.
  6. Kolejne osoby wykonują swoje ruchy w kółko aż to momentu, kiedy zostaną oszacowane wszystkie karty.
  7. Każdy wykonując ruch uzasadnia swoją decyzję, a pozostali mogą zadawać pytania wyjaśniające ale nie mogą podważać oszacowania osoby wykonującej ruch.
  8. Na koniec można zrobić dodatkową rundkę (albo kilka) na opcjonalny ostatni ruch.
  9. W rezultacie powinniśmy otrzymać kilka grup kart o zbliżonych estymatach. Jeżeli grup jest zbyt dużo, możemy zdecydować się na połączenie kilku.
  10. Następnie przypisujemy tym grupom wartości w story pointach, np. z ciągu Fibonacciego.

    Karty ułożone podczas Team Estimation Game

    Karty ułożone podczas Team Estimation Game

Oczywiście o moderację nadal należy dbać. Tu też zdarzają się falstarty (ktoś przesunie coś nie czekając na swoją kolej) albo wpływanie na czyjąś decyzję („Tutaj?! No bez przesady… Ja bym dał to niżej!”).

Najciekawsze na koniec

Z moich doświadczeń najważniejsza jest jednak końcówka. W Planning Pokerze sesja estymacyjna najczęściej kończyła się albo po upływie zaplanowanego czasu (rzadko, częściej spotkania się przeciągały), albo po oszacowaniu ostatniej historyjki. Zespół po prostu kończył spotkanie i rozchodził się.

W Team Estimation Game gra tylko teoretycznie się kończy po oszacowaniu ostatniej karty ze stosu i opcjonalnej dodatkowej rundzie. W rzeczywistości po ostatniej rundzie zespół najczęściej wstaje i wszyscy wspólnie jeszcze raz się pochylają (dosłownie) nad wyłożonymi na stół historyjkami, żeby „na koniec rzucić okiem” i zaczynają zadawać naprawdę ważne pytania, jeszcze coś zespołowo doprecyzowują, przesuwają, aż rzeczywiście cały zespół będzie zgodny co do tego, jak całość jest ułożona.

Kolejne sesje estymacyjne

Rzadko kiedy mamy do oszacowania zupełnie nowy Backlog Produktu. Najczęściej szacujemy nowe historyjki w ciągle utrzymywanym Backlogu. Wtedy jako punkt odniesienia zamiast pierwszej karty ze stosu lepiej użyć kilku już wcześniej oszacowanych (albo wręcz zaimplementowanych) historyjek o różnych rozmiarach, np. po jednej za 1, 5 i 13 punktów.

Wariant niemy

Można ustalić, że jedynie osoba wykonująca aktualnie ruch może się odzywać po to, żeby zadać pytania Product Ownerowi. Nikt inny z zespołu nie może komentować ruchu. Wyłapujemy w ten sposób „wędrujące” historyjki, ale w miarę, jak kolejne osoby zadają pytania, a Product Owner odpowiada, w końcu znajdują one swoje miejsce na stole albo są odkładane na bok do dyskusji na później.

Zalety Team Estimation Game

  • Relatywne szacowanie. Deweloperzy nie muszą od razu odpowiadać na pytanie „ile?”, a jedynie porównują ze sobą karty. Łatwiej jest powiedzieć, która z historyjek jest większa/mniejsza, niekoniecznie określając, jak bardzo.
  • Punkt odniesienia. Nie tracimy z oczu już oszacowanych historyjek, dzięki czemu cały czas mamy dobry punkt odniesienia dla kolejnych.
  • Korygujemy estymaty. Dość powszechne jest wracanie do już oszacowanej historyjki i ponowne jej szacowanie, dzięki czemu może być ono dokładniejsze (w odróżnieniu od Planning Pokera, kiedy o historyjce zapominano zaraz po jej oszacowaniu).
  • Perspektywa zespołu. Historyjki są szacowane z punktu widzenia całego zespołu. W Planning Pokerze każdy z osobna szacował bardziej ze swojej specjalistycznej perspektywy.
  • Brak oporu w przypadku niepewności. Jeżeli ktoś z zespołu ma problem z oszacowaniem którejś z historyjek, nic strasznego — może położyć ją gdziekolwiek, a koledzy poprawią w następnych ruchach.
  • Jest szybciej. Nie tracimy czasu na historyjki, co do których jest zgoda, a dyskusja toczy się jedynie wokół tych przesuwanych.
  • Każdy głos może być usłyszany. Osoby cichsze nie są tak łatwo zagłuszane przez gaduły, jak to często ma miejsce przy Planning Pokerze, a cała dyskusja przebiega sprawniej i jest bardziej merytoryczna.
  • Skalowanie. Technikę można z powodzeniem stosować w bardziej licznych zespołach albo gdy kilka zespołów pracuje z jednym Backlogiem Produktu. Zdarzyło mi się zastosować wariant niemy z niemal 20-to osobową grupą.

Oryginalny pomysł Team Estimation Game przypisuje się Steve’owi Bockmanowi, a ściągę z regułami można znaleźć na stronie agile42.com.

Categories: Estymacja.

Comment Feed

4 komentarze

  1. Bardzo dobra alternatywa, dzięki za ten pomysł, rozwiązuje częsty problem ze zwykłego pokera o którym piszesz czyli wahania się między kolejnymi wartościami.
    Zdecydowanie łatwiej jest porównać do siebie poszczególne elementy backlogu i ocenić , które są większe, które mniejsze niż po prostu rzucać z kapelusza jakieś wartości czy przyrównywać je tylko do jednej historyjki referencyjnej. Śmiało mogę polecić każdemu zespołowi scrumowemu.

  2. Paulina1 lutego 2016 @ 14:29

    To pdoejście u nas sprawdziło się dużo lepiej niż Poker, zastosowane na jednym ze spotkań już zostało, po prostu jest dla nas naturalne :)
    Także polecamy :)

  3. Ciekawe, sprawdzimy to u siebie w zespole jako alternatywę do Poker Planning :)

  4. Zrobiłam dziś pierwsze podejście dla wcześniej oszacowanych zadań. Efekty:
    – każdy deweloper MUSIAŁ przeczytać opis zadania, żeby móc położyć w odpowiednim miejscu; jeżeli coś było dla niego niezrozumiałe albo już zapomniał skąd takie kryteria itd. – zadawał pytania,
    – wywiązała się dyskusja DLACZEGO coś jest większe/mniejsze od innego zadania, dyskusja o tym, co wiemy, a czego nie wiemy i jakie niesie to ze sobą ryzyko,
    – wzrosło zaangażowanie zespołu, bo każdy był w ruchu i nie przysypiał,
    – okazało się, że estymaty po tej zabawie w niektórych zadaniach drastycznie się zmieniły (mimo, że wcześniej też były wyceniane) – w większości na większe niż były wcześniej. Może dlatego, że rozmowy na temat historyjek były bardziej merytoryczne niż skupianie się „To 2 czy 3 punkty? „



Some HTML is OK

or, reply to this post via trackback.