Dzień 9 – Planning Poker

Ten post jest częścią cyklu Pierwsze Dni Scrum.

W pewnej firmie korytarzem przechadza się nowy manager. Zagląda przez uchylone drzwi do salki konferencyjnej, a tam? O zgrozo! Developerzy siedzą i grają w karty? Cóż za bezczelność! Jest jednak nowy więc zanim zgłosi przestępców do HR postanawia bliżej zbadać temat. Wchodzi do salki a tam…

Jak działa Planning Poker?

W kontekście Scrum Planning Poker to metoda szybkiego i skutecznego szacowania względnego rozmiaru elementów backlogu przez zespół, który będzie je realizował, używając umownych jednostek znanych punktami (lub pingwinami).

W Planning Poker gra się talią zawierającą karty: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, nieskończoność, ? i kawa.

Rozgrywka przebiega następująco:

Zespół wybiera element backlogu, który sprawia wrażenie najmniejszego i arbitralnie przypisuje mu jednego pingwina, a następnie dla każdego kolejnego elementu backlogu:

1. Właściciel Produktu wyjaśnia znaczenie i kontekst elementu i odpowiada na pytania zespołu.
2. Po chwili zespół przystępuje do szacowania:
   • Każdy członek zespołu szacuje jak ma się omawiany element do wzorcowego, uwzględniając pracę całego zespołu.
   • Gdy gracz zdecyduje jakie jest jego oszacowanie, wykłada odpowiednią kartę tak, by inni nie widzieli jej wartości.
3. Gdy wszyscy już dokonają swojego wyboru karty są odkrywane:
   • Jeśli oszacowanie jest zgodne to zapisujemy wynik i przechodzimy do następnego elementu.
   • Jeśli oszacowania różnią się co najwyżej o jeden przeskok to bierzemy wyższe oszacowanie i przechodzimy do następnego elementu.
   • Jeśli różnica jest większa to osoby, które zagrały najniżej i najwyżej wyjaśniają swoją decyzję.
   • Jeśli wynikiem szacowania jest nieskończoność oznacza to, że historyjka jest za duża do oszacowania.
   • Jeśli ktoś zagra ?, oznacza to, że historyjka wymaga dalszego wyjaśnienia.
   • Jeśli ktoś zagra kawa to znaczy, że czas na przerwę regeneracyjną.
4. Jeśli jest to konieczne to powtarzamy rundę – gracze wykładają zakryte karty uwzględniając wnioski z dyskusji.
5. Rundy szacowania są powtarzan do skutku lub do znudzenia. Jeśli zespół nie będzie w stanie dojść do porozumienia w 3-4 rundy to znaczy, że historyjka wymaga dopracowania (np. przeformułowania, podzielenia lub okrojenia).

Dlaczego Planning Poker?

Zamiast wyliczać najczęściej przytaczane zalety Planning Pokera odeślę Was choćby do fragmentu książki Mike’a Cohn’a “Agile Estimation & Planning” a tutaj skoncentrujemy się na dwóch rzadziej omawianych korzyściach, która mogą mieć większe znaczenie niż wynikowe oszacowanie:

Planning Poker stymuluje dyskusję o tym, co ma być zrobione – liczby, które wychodzą z sesji PP są ważne, ale jeszcze ważniejsze od nich są dyskusje podczas szacownia! W ten sposób masowo odkrywane są ukryte założenia przyjmowane przez uczestników, zarówno co do zakresu jak i sposobu realizacji prac. Wszystkie ustalenia pojawiające się w czasie tych dyskusji powinny zostać zapisane w formie kryteriów akceptacji dla szacowanego elementu, żeby później uniknąć wątpliwości na temat jego realizacji i późniejszego odbioru przez PO.

Planning Poker wspiera formowanie się zespołu – dyskusja wokół szacowania kolejnych fragmentów backlogu konfrontuje zespół z potrzebą dojścia do wspólnego zrozumienia zakresu zadań i sposobu ich realizacji. Scrum Master powinien dbać o to, żeby podczas szacowania zespół występował jako spójna, współodpowiedzialna jednostka. Nieporządane są sytuacje, w których jeden z członków zespołu zrezygnowałby z wyrażenia swojej opinii lub odmówił komuś innemu takiego prawa ze względu np. na “brak kompetencji w danej specjalności”. Faktem jest (i Scrum Master powinien o tym w razie potrzeby przypomnieć), że każdy członek zespołu wnosi istotną wartość do całego procesu. W przeciwnym wypadku nie byłby członkiem tego zespołu!

Może coś prostszego?

Nie zawsze potrzebujemy szacować z tak dużą rozdzielczością, jaką oferuje Planning Poker. Jeśli dodatkowy wysiłek nie przełoży się na możliwość podejmowania lepszych decyzji to może nam wystarczyć prostszy system szacowania, w której każdemu elementowi backlogu przypisujemy jeden z trzech rozmiarów: S, M i L, które można wyskalować np. tak:

• S – możemy zrobić ~10 takich elementów w sprincie,
• M – mniej więcej trzy w sprincie,
• L – wypełnia prawie cały sprint.

Wszystkie większe historyjki oznaczamy jako za duże i przed oszacowaniem okrajamy lub rozbijamy na mniejsze.

Wymaga to większego wysiłku, by nieco znormalizować rozmiar proponowanych historyjek, ale wysiłek ten może z nawiązką zwrócić się poprzez wyższą jakość backlogu, który w ten sposób powstanie. Uproszczona komunikacja podczas szacowania elementów jest zastąpiona dyskusją o ich podziale. Tracimy za to możliwość zgrubnego oszacowania dużych historyjek przed ich rozbiciem.

Idąc dalej możemy zamiast na szacowaniu różnorodnych elementów skoncentrować się na podziale kolejnych ulepszeń w taki sposób, by wszystkie miały podobny rozmiar. Ta metoda nie jest często stosowana, ale na pewno powinna znaleźć się wśród dostępnych narzędzi.

W skrajnym przypadku możemy w ogóle nie przejmować się szacowaniem. Np. twórcy gier komputerowych dysponujący odpowiednio dużym budżetem (np. Valve) często rozwijają produkt, aż uznają, że jest gotowy, nie stosując żadnych metod formalnego obliczania, kiedy to może nastąpić.

Zadanie dla Was:

1. Jak szacujecie rozmiar planowanych prac?
2. Czy w szacowaniu zaangażowane są wszystkie osoby, które będą odpowiedzialne za realizację (czyli cały zespół)?
3. Czy to szacowanie pozwala Wam podejmować lepsze decyzje?
4. Spróbujcie oszacować przykładową porcję wymagań za pomocą prostszej metody, niż zwykle stosujecie.