Planning Poker – jak szacować czas realizacji zadań w Scrum?

Jak to zmienić? Jak doprowadzić do tego, aby szacowanie nie do końca było zabawą w zgadywanie, a coraz częściej dostarczało przewidywalne i sprawdzające się estymacje?

Tutaj z pomocą przychodzi sympatyczna technika zwana Planning Poker.

Czym jest Planning Poker?

Metoda ta została po raz pierwszy opisana w 2002 roku w krótkim artykule autorstwa James’a Grenning’a. Następnie została dokładniej omówiona Przez Mike’a Cohn’a w książce Agile Estimating and Planning. Firma Cohn’a, Mountain Goat Software jest właścicielem znaku towarowego Planning Poker oraz posiada patent na sekwencje wartości.

Nazwa tej metody wzięła się stąd, że w szacowaniu używamy kart oraz tego jak one są odkrywane. 

Przeczytaj także: 

W centrum wyzwań IT Managera. 10 edycja konferencji IT Manager of Tomorrow

Zapraszamy na wyjątkową, jubileuszową edycję pod hasłem #TheBestOfITMT. Czas na crème de la crème dziesięciu edycji. Bądźcie z nami od 23 do 26 czerwca 2025 roku w Gdyni.

Jak początkujący Manager IT może zbudować efektywny zespół?

Wejście w rolę Managera IT to wyzwanie, które wymaga nie tylko znajomości technologii, ale przede wszystkim umiejętności zarządzania zespołem.

 

Jak działa Planning Poker, czyli skuteczna metoda szacowania w Scrum

W metodzie nie używamy czasu pracy jaki potrzebny jest do zrealizowania założonego User Stories, ale tak zwanych Story Points, które pokazują złożoność historyjek względem siebie, bo estymacja zadań w scrum to jeden z kluczowych elementów gry. 

W grze biorą udział wszyscy członkowie zespołu włącznie z Product Ownerem lub Kierownikiem Projektu. Każdy z nich musi posiadać komplet kart z różnymi wartościami; głównie wykorzystywany jest model z wartościami liczbowymi, ale zdarzają się również modele z np. wartościami znanymi z rozmiarów koszulek. Ważne jest, aby wartości nie były liniowe więc często wykorzystuje się wartości zawierające skalę wykładniczą, ciąg Fibonacciego lub - co jest wykorzystywane w oryginalnym Planning Poker - zmodyfikowany ciąg Fibonacciego czyli liczby 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 i 100. Czasem dokłada się jeszcze dwie dodatkowe karty – np. ?, które określają, że członek zespołu nie potrafi określić czasu produkcji danej historyjki.

Planning Poker: Skuteczne szacowanie czasu realizacji w Agile

Sesję zaczyna się od wybrania teoretycznie najprostszej lub najłatwiejszej w oszacowaniu Historyjki takiej, którą będziemy mogli oszacować np. na 1SP lub np. na 5SP. Aby ułatwić to zadania dobrze jest zapisać na tablicy szacowania SP dla kilku typowych User Stories .

Moderator czyta po kolei User Stories, a po każdej z nich członkowie zespołu wyciągają karty z taką ilością SP, które ich zdaniem powinna mieć dana historyjka.

Jeżeli wartości znacząco się różnią, to właściciele największej i najmniejszej ilości wskazanych SP opowiadają, dlaczego wybrali właśnie takie karty, po czym ponawiane jest głosowanie. W tym procesie nie chodzi obronę własnej tezy, a jedynie wskazanie czynników, które były przez nich brane pod uwagę tak, aby ponownie rozpatrzył je cały zespół. Może to być kwestia związana z tym, że w firmie pojawia się nowa nieznana technologia, mamy nowego członka w zespole i testowanie może się wydłużyć lub np. faktu, że podobne rozwiązanie kiedyś było już napisane i nie trzeba wymyślać koła od nowa.

Po 2-3 głosowaniach, zespół zazwyczaj jest zgodny lub różnice są niewielkie i można przyjąć jakąś metodę oceny np. wybór większością głosów lub ostatecznie decyduje lider.

Zalety stosowania Planning Poker w Scrum

• Każdy z członków pracuje indywidualnie i nie opiera się tylko na wiedzy lidera z danej dziedziny
• Porównywanie historyjek na zasadzie „ta będzie większa od 8, ale mniejsza od 20, więc zróbmy z niej 13”
• Szybkość – na godzinnym spotkaniu można ocenić naprawdę sporo historyjek
• Historyjki są przedyskutowane w gronie expertów mających wiedzę porównawczą z poprzednich szacowań

Co zrobić jak nie mamy kart do Planning Pokera?

• Można wykorzystać karteczki z wypisanymi liczbami
• Można użyć kilku dostępnych na telefony aplikacji
• Można skorzystać z darmowej wersji aplikacji webowej

Jak przełożyć szacowanie na realny czas projektu?

Tutaj mamy dwie możliwości:

1. Na początku wybraliśmy najłatwiejszą w ocenie historyjkę. W pewnym przybliżeniu możemy określić więc czas jej trwania w godzinach, a następnie porównać to z pozostałymi historyjkami. Uda nam się określić ile czasu potrzebujemy na realizację wszystkich User Stories.
2. Częściej stosowaną metodą jest określenie Prędkości (ang. Velocity) Zespołu, np. na 40 SP/sprint. Zapewne to podejście na początku będzie obarczone pewnymi błędami ale w kolejnych iteracjach nasze estymacje będą zdecydowanie bardziej precyzyjne niż w tradycyjnej metodzie planowania.
   
   

Po więcej informacji odsyłam do książki Agile Estimation Practices – Demystifying Story Points, autorstwa Johna Donovana.