Wróć do wszystkich wpisów

4 min czytania

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

Paweł Cichoń

Post image

Jak często zdarza Ci się  szacować czas pracy jaki Wasze zespoły muszą poświęcić na zadania, które będą musiały zostać zrealizowane w sprincie czy timebox'ie?

Czy Tobie lub Twoim managerom lub kierownikom projektu zdarza się stosować magiczny mnożnik, aby urealnić czas zadań, który jest Twoim zdaniem błędnie określony przez zespół developerski?

 

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 do zrealizowania założonego User Stories, ale 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 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.

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

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.

 

Kategorie: Agile Scrum

Nie zapomnij udostępnić tego postu

Wiedza i inspiracje prosto na Twój mail

Zostaw swój email, a będziemy regularnie informować Cię o nowych artykułach.

Spis treści