Zasady Planning Pokera: ustalenia dla zespołu
Kto szacuje, kiedy odkrywać karty i jak potraktować pytanie, którego liczba nie rozwiąże? Praktyczne zasady z przykładem rozmowy.
Podstawowe zasady Planning Pokera to szacowanie tego samego zakresu, niezależny wybór kart, wspólne odkrycie i omówienie przyczyn różnic przed zapisaniem wyniku. Ustalcie, kto głosuje i kiedy potrzebna jest odpowiedź zamiast wymuszonej liczby.
„To przecież dwójka, prawda?” Jedno zdanie może wpłynąć na kolejne głosowanie. Osoba, która myślała o ósemce, zaczyna bronić swojej oceny, zanim pokaże kartę. Kilka wspólnych ustaleń pozwala każdemu najpierw pomyśleć.
Niezależny wybór i wspólne odkrycie opisuje Agile Alliance. Propozycje rozwiązywania wyjątków poniżej możecie dopasować do zespołu. Przygotowanie i przebieg spotkania znajdziecie w poradniku Planning Pokera krok po kroku.
W tym poradniku
Gdy głosy oznaczają różne wymagania
Fikcyjny zespół szacuje: „Umożliwić administratorowi anulowanie nieprzyjętego zaproszenia do przestrzeni roboczej”. Karty pokazują 2, 2, 5 i ?.
Osoba z
2: „Po prostu unieważniamy istniejące zaproszenie”.Osoba z
5: „A jeśli ktoś przyjmie je dokładnie w tym momencie?”Osoba z
?: „Jeśli już dołączył, mamy też usunąć członka?”
Wybranie najczęstszej liczby pozostawiłoby pytania bez odpowiedzi. Osoba prowadząca prosi Product Ownera o rozdzielenie wycofania oczekującego zaproszenia od usunięcia istniejącego członka. Usunięcie staje się osobnym wymaganiem. Nadal trzeba ustalić zachowanie przy jednoczesnym przyjęciu i anulowaniu zaproszenia.
Runda kończy się pytaniem i wskazaniem osoby, która je wyjaśni. Po zapisaniu decyzji zespół może oszacować doprecyzowane zadanie. Ostateczna liczba nie jest jeszcze potrzebna.
Głosowanie porównuje rozumienie pracy; nie określa zachowania produktu. Liczby ilustrują tę rozmowę, nie są uniwersalnym oszacowaniem funkcji zaproszeń.
Zasady przed głosowaniem
| Zasada | Znaczenie w praktyce |
|---|---|
| Szacujcie wspólny zakres | Pokażcie oczekiwane zachowanie i granice. Poprzednie głosy dotyczą poprzedniego zakresu. |
| Wybierzcie jednostkę i talię | Story points lub inna jednostka; nie mieszajcie godzin z rozmiarem względnym w jednej rundzie. |
| Niech szacują osoby wykonujące pracę | Uwzględnijcie wiedzę potrzebną do ukończenia, bez dodatkowej wagi za stanowisko czy staż. |
| Wybierajcie niezależnie, odkrywajcie wspólnie | Nie sugerujcie liczby docelowej ani nie odkrywajcie kart, gdy ktoś nadal wybiera. |
| Omawiajcie założenia stojące za kartami | Wysłuchajcie niskich, wysokich ocen i innych uwag. Mniejszość mogła zauważyć pominiętą pracę. |
| Rozróżniajcie sygnały nieliczbowe | Pytanie, pominięcie szacowania i prośba o przerwę nie są ocenami liczbowymi. |
| Ustalcie zakończenie lub zatrzymanie | Zapiszcie ocenę, której zespół może użyć, albo pytanie wymagające wcześniejszej odpowiedzi. |
| Szacujcie ponownie przy nowej informacji | Zmiana zakresu może tego wymagać; pożądana suma w raporcie nie zmienia pracy. |
Korzystajcie z ukończonych zadań jako punktów odniesienia. Przykłady story points pokazują, jak opisać ich granice, a poradnik skali Fibonacciego wyjaśnia talię i odstępy. Te zasady nie wymagają konkretnej talii ani stałego przelicznika na godziny.
Kto szacuje i kto prowadzi
Według Scrum Guide, w części Product Backlog, za rozmiar odpowiadają Developers wykonujący pracę. To osoby tworzące użyteczny Przyrost, także dzięki umiejętnościom innym niż programowanie. Scrum nie wymaga Planning Pokera ani nie określa zasad jego wyjątków.
Tester może zapytać: „Co się stanie, jeśli administrator utraci uprawnienia w trakcie operacji?” To część oceny całego zadania, nie osobne oszacowanie QA dodawana do punktów frontendu i backendu.
Product Owner wyjaśnia rezultat i pomaga określić, co wchodzi w zakres. Osoba prowadząca pilnuje, by nikt nie podpowiadał oczekiwanej liczby. Żadna z tych ról nie daje dodatkowego głosu. Jeśli ktoś uczestniczy też w realizacji, wyjaśnijcie, z jakiej perspektywy szacuje. Rozróżnienie opisuje Mountain Goat Software.
Przed odkryciem ustalcie, kto szacuje dany element. Obserwator nie musi podawać liczby tylko po to, by cała lista uczestników zagłosowała.
Gdy runda nie idzie zgodnie z planem
Ktoś wybiera znak zapytania albo pomija ocenę
„Wybrałem ?, bo nie wiem, czy stare zaproszenia mają pozostać ważne”. Jest konkretne pytanie. Uzupełnijcie brakujący kontekst, zamiast po cichu usuwać kartę z wyniku.
?: potrzebuję odpowiedzi, zanim oszacuję.- Pominięcie: nie podaję oceny tego elementu.
0, jeśli jest w talii: wartość liczbowa o znaczeniu ustalonym przez zespół.
Pominięcie nie oznacza zera ani milczącej zgody. Jeśli ujawnia brak niezbędnej wiedzy, odnotujcie tę lukę. Karta przerwy to osobna prośba o odpoczynek.
Brakuje potrzebnej osoby
„Nasz specjalista od baz danych stracił połączenie. Możemy kontynuować?” Jeśli zespół rozumie tę część pracy, tak. Jeżeli jego odpowiedź może zmienić rozwiązanie, zapiszcie pytanie i odłóżcie szacowanie. Nieobecność nie oznacza zgody.
Liczba pada przed odkryciem
„To na pewno dwójka”. Zatrzymajcie się i wróćcie do zakresu. Każdy ponownie wybiera niezależnie; jeśli karty są już odkryte, zacznijcie nową rundę. Powtórka nie usuwa usłyszanej liczby z pamięci, dlatego wprost zaproście do innych ocen.
Po głosowaniu zmienia się wymaganie
„Przy okazji musimy wycofać też zaproszenia z zeszłego miesiąca”. To nowa informacja. Zaktualizujcie kryteria akceptacji przed kolejnym szacowaniem. Poprzedni wynik dotyczył poprzedniego zakresu.
Głosy nadal się różnią lub ktoś chce mniejszej liczby
Znowu piątki i ósemki? Zapytajcie: „Jaką pracę uwzględniliście, którą inni mogli pominąć?” Przy tym samym zakresie porównajcie zadania referencyjne. Przy różnych wymaganiach najpierw ustalcie zakres.
Istniejący zrzut Agilo z fikcyjnymi uczestnikami i angielskim interfejsem. Średnia 5,3 nie wyjaśnia różnicy. Revote umożliwia kolejną rundę; zespół decyduje, czy najpierw potrzebne jest wyjaśnienie lub inny krok.
„Potrzebujemy tego w tym tygodniu, możecie wpisać trzy?” To rozmowa o zakresie i priorytetach. Ustalcie, co można usunąć lub zmienić. Mniejsza karta sama nie usuwa pracy.
Agile Alliance ostrzega przed wymuszoną zbieżnością. Zespół może przyjąć ocenę, choć nie każdy osobiście preferuje tę samą kartę. Wysłuchajcie zastrzeżeń i zatrzymajcie się, jeśli liczba ukrywa nierozwiązane wymaganie. Ani średnia, ani decyzja najbardziej doświadczonej osoby go nie rozstrzygną.
Ustalenia zespołu do skopiowania
Dodajcie tekst do notatek i uzupełnijcie nawiasy. Powinien dać się przeczytać przed pierwszym głosowaniem. To ustalenia zespołu, nie ustawienia automatycznie wymuszane przez narzędzie.
Talia i jednostka: [wybierzcie]. Referencje: [link].
Ten element szacują: [osoby/umiejętności].
Prowadzenie: [imię]. Pytania produktowe: [osoba odpowiedzialna].
Ustalamy zakres, wybieramy niezależnie i odkrywamy wspólnie.
Nie podpowiadamy docelowej liczby przed odkryciem.
Słuchamy przyczyn różnic i pozostałych zastrzeżeń.
? oznacza pytanie; pominięcie nie jest zerem ani zgodą.
Granica dyskusji: [czas lub warunek zatrzymania].
Nowy zakres oznacza aktualizację wymagań i ponowne szacowanie.
Zapisujemy liczbę, gdy szacujący mogą wspólnie z niej korzystać.
Brakuje kontekstu lub wiedzy: pytanie → odpowiedzialna osoba → następny krok.
Szacujemy ponownie z powodu nowej informacji, nie pożądanej sumy.
Granica dyskusji pomaga wybrać kolejny krok, nie wyznacza terminu wymuszonej jednomyślności. Zmieńcie ustalenia, jeśli utrudniają udział lub ukrywają niepewność.
Wykorzystajcie ustalenia w Agilo
Zachowajcie zasady w notatkach i głosujcie w Agilo Planning Poker. Wybierzcie ustaloną talię, ukryjcie głosy do odkrycia i zacznijcie nową rundę, gdy zmienia się zakres. Wbudowane systemy oferują znak zapytania, kartę przerwy i możliwość pominięcia oceny; reakcję ustala zespół.
Utwórzcie pokój Planning Pokera, gdy uczestnicy, zakres i zasady będą jasne. Pełny przebieg opisuje poradnik prowadzenia spotkania.
Źródła
- Agile Alliance: Planning Poker — praktyka i ryzyko wymuszonej zgody.
- Oficjalny Scrum Guide — odpowiedzialność za rozmiar; Planning Poker nie jest obowiązkowy.
- Mountain Goat Software: Planning Poker — udział i karty nieliczbowe.
