Planning poker - czyli jak szacować czas potrzebny na realizację zadania

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.

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.

Jak działa planning poker?

W metodzie nie używamy czasu pracy jaki potrzebny jest na zrealizowanie założonego User Stories a tak zwanych Story Points, które pokazują złożoność historyjek względem siebie.

W grze biorą udział wszyscy członkowie zespołu włącznie z Produkt 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 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óry określa, że dany członek zespołu nie potrafi określić czasu produkcji danej historyjki.

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.

Jakie są zalety wykorzystania planning pokera?

• 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 http://planningpoker.com/

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

Tutaj mamy dwie możliwości:

1. Na początku wybraliśmy najłatwiejszą w szacowaniu Historyjkę – pewnie 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 estymaty będą zdecydowanie bardziej precyzyjne niż w tradycyjnej metodzie planowania.

Po więcej informacji odsyłam do: „Agile Estimation Practise – Demystifying Story Points” – John Donovan.