Na problemy związane z estymowaniem zadań oraz dokładnością oszacowań prędzej czy później trafi każdy Product Manager. Możliwych do wykorzystania metod estymacji jest wiele i w różnym stopniu sprawdzają się one na poszczególnych poziomach zarządzania produktem. Inny poziom dokładności “wyceny” jest istotny dla zadań wchodzących w zakres najbliższego sprintu, a inny dla epików, które mają być częścią wydania produktu zaplanowanego na drugi kwartał kolejnego roku.

Podczas drugiego Product MeetUp’u oraz tegorocznej edycji Konferencji Inżynierii Oprogramowania beIT jako Product Crew przeprowadziliśmy warsztaty, w trakcie których wraz z uczestnikami sprawdziliśmy w praktyce trzy z najpopularniejszych metod – estymowanie absolutne, Planning Poker oraz Team Estimation Game.

Estymowanie absolutne

Powszechnie znana metoda, która polega na „wycenie” pracochłonności danego zadania w godzinach. Pozornie prosta, jednak podczas jej wykorzystania można natrafić na przynajmniej kilka zagwozdek:

  • ile rzeczywiście godzin dziennie pracuje programista?
  • czy godzina pracy doświadczonego programisty równa jest godzinie pracy stażysty?

Planning Poker

Jest to metoda, która wywodzi się z metod zwinnych jak Scrum czy programowanie ekstremalne i najlepiej sprawdza się w kombinacji z jednostkami relatywnymi takimi jak story point’y. Podczas warsztatów wykorzystaliśmy liczby z ciągu Fibonacciego w zakresie od 1 do 21 (1, 2, 3, 5, 8, 13 oraz 21), ale jest to kwestia umowna – należy jednak pamiętać, że im większa wycena tym zazwyczaj bardziej niedokładna.

Aby przeprowadzić efektywną sesje Planning Pokera każdy z graczy (zazwyczaj członkowie zespołu programistycznego) otrzymuje talię kart, gdzie każda z kart reprezentuje kolejną możliwą wartość wyceny. Taką talię bardzo często rozszerza się również o karty specjalne np. z symbolem nieskończoności (przez którą wyrażamy, że naszym zdaniem dane zadanie jest zbyt duże, aby je dokładnie wyestymować) oraz filiżankę kawy (sygnalizujemy, że potrzebujemy przerwy). Istotną rolę odgrywa również dobrze przygotowany Product Owner bądź Product Manager. Jego zadaniem jest przedstawić zespołowi zakres danego zadania oraz odpowiedzieć na ewentualne pytania.

Kiedy wszystkie wątpliwości zostaną rozwiane, zespół przystępuje do estymacji – na wcześniej ustalony znak (np. trzy-czte-ry) wszyscy gracze wykładają na stół karty z proponowanymi przez siebie wycenami. Jeżeli zaproponowane wartości różnią się od siebie, zadaniem osób z najmniejszą i największą wartością jest uzasadnienie swojego wyboru (bardzo często pojawiają się tutaj dodatkowe pytania i dyskusje). Następnie czynność jest powtarzana – każdy z graczy w tajemnicy ponownie wybiera kartę (może być to zarówno ta sama jak i inna karta) i karty ponownie są odkrywane. Idealnie, jeżeli po dwóch lub trzech partiach uda uzyskać się konsensus – warto zadbać o obecność moderatora sesji np. Scrum Master’a.

cards
Źródło: https://www.mountaingoatsoftware.com/blog/3-roles-that-need-to-be-involved-in-agile-estimating-with-planning-poker

Team Estimation Game

To metoda, która również wykorzystuje story point’y. Wymaga krótkiego przygotowania: wydrukowania i ułożenia na stosie wszystkich zadań, które mają zostać oszacowane oraz przygotowania kart z wartościami liczbowymi reprezentującymi ustalony zakres możliwych wycen (np. od 1 do 21). Uczestnicy gry, czyli tak jak w przypadku Planning Pokera, najczęściej członkowie zespołu programistycznego mają za zadanie uporządkowanie wszystkich zadań od najmniejszego do największego. Oczywiście również tutaj nie da się pominąć roli dobrze przygotowanego Product Managera, który wyjaśnia wszystkie pojawiające się wątpliwości.

Gra toczy się zgodnie z kierunkiem ruchu wskazówek zegara. Pierwszy gracz bierze pierwszą kartę ze stosu, czyta ją na głos i kładzie na środek stołu. Drugi gracz bierze kolejną, czyta i wykonać może jeden z dwóch możliwych ruchów – położyć kartę po lewej lub po prawej stronie karty, która już znajduje się na stole jednocześnie uzasadniając swoją decyzję. Położenie karty po lewej stronie oznacza, że zdaniem tego gracza pracochłonność zadania jest mniejsza od pracochłonności pierwszego zadania, po prawej, że jest od niej większa.

Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/
Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/

Trzeci gracz z kolei może albo wziąć następną kartę ze stosu lub zmienić położenie jednej z kart znajdujących się już na stole, powinien jednak pamiętać o uzasadnieniu swojej decyzji. Kolejni gracze mają do dyspozycji te same ruchy, a pierwszy etap gry toczy się do momentu rozłożenia na stole wszystkich kart ze stosu. Następnie (z utrzymaniem kolejności zgodnej z ruchem wskazówek zegara) gracze mogą modyfikować pozycje dowolnie wybranej karty na stole, lub jeżeli zgadzają się z aktualnym ułożeniem wszystkich kart, spasować. Jeżeli wśród wszystkich graczy zapanuje zgoda, przechodzi się do ostatniego etapu.

Celem ostatniego etapu jest ułożenie kart w grupy, którym przypisuje się wspólne wyceny. Na początku kartę reprezentującą najmniejszą możliwą wycenę np. 1 umieszcza się nad ostatnią kartą po lewej stronie (najmniejsza pracochłonność). Następnie pierwszy gracz otrzymuje kartę z następną możliwą wartością estymaty np. 2 i wybiera dla niej miejsce „w szeregu”.

Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/
Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/

Każdy następny gracz albo bierze kolejną kartę z estymacją lub zmienia pozycje dowolnej karty znajdującej się już na stole (dotyczy to zarówno kart z zadaniami jak i tych reprezentujących wyceny). Gra toczy się do momentu, kiedy uda się pogrupować wszystkie zadania w pionowe kolumny. Warto zaznaczyć, że nie wszystkie karty z wycenami muszą zostać ostatecznie wykorzystane, najważniejsze jest osiągnięcie konsensusu.

Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/
Źródło: http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/

Podsumowanie

Podczas przeprowadzonych warsztatów mieliśmy przyjemność uczestniczyć w bardzo interesujących dyskusjach oraz podsumowaniach. W dużym skrócie nie ma idealnej metody – każda z nich posiada zarówno wady jaki i zalety. Jednak aby pomóc Ci w ostatecznym wyborze przygotowaliśmy poniższą infografikę podsumowującą – mamy nadzieję, że okaże się pomocna!

plusy-i-minusy-metod-estymacji-zadan

Błyskotliwe pomysły i katastrofalne decyzje.
Otrzymaj nasze lessons learned z tworzenia produktów.

Wyślemy Ci najnowsze artykuły, case studies, porady

+ unikalne materiały tylko dla czytelników newslettera


PODZIEL SIĘ
Od najmłodszych lat związany z Internetem. Aktualnie programista aplikacji internetowych zarówno po stronie serwera jak i klienta. Od ponad trzech lat tworzę i rozwijam produkty dla międzynarodowych startupów.Na co dzień pracuję w Scrumie (certyfikowany Scrum Master) zwinnie wykorzystując praktyki Agile - ciągłą integrację, regularny refaktoring oraz przegląd kodu.Po pracy czytam o i eksperymentuje z nowymi technologiami.

ZOSTAW ODPOWIEDŹ