Dziś na warsztat bierzemy temat, który prędzej czy później spędza sen z powiek każdemu Product Managerowi - estymowanie zadań. 🤯 Mówiąc wprost: jak wycenić, ile czasu i wysiłku pochłonie dane zadanie, żeby zespół wiedział, na czym stoi, a stakeholderzy nie patrzyli na nas jak na wróżbitów z kryształowej kuli.

Nie ma co się oszukiwać, dokładniejsze estymaty pozwalają zwiększyć przewidywalność pracy zespołu.

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 precyzji potrzebujemy dla zadań, które wchodzą do najbliższego sprintu, a inny dla epików, które mają być częścią produktu planowanego na następny rok.

Poniżej przyjrzymy się trzem najpopularniejszym metodom estymacji: 1️⃣ Estymowanie absolutne, 2️⃣ Planning Poker oraz 3️⃣ Team Estimation Game. Dziś rozłożę je dla Was na czynniki pierwsze, dorzucając moje własne spostrzeżenia z frontu.

1️⃣ Estymowanie absolutne (wycena godzinowa)

To metoda, którą znasz pewnie od zawsze. Polega na „wycenie” pracochłonności zadania w konkretnych jednostkach czasu, najczęściej w godzinach.

Jak to działa?

Zespół po prostu podaje konkretną liczbę godzin, którą ich zdaniem zajmie wykonanie zadania.

Moje obserwacje:

• Subiektywność nad obiektywność: Pamiętam, jak kiedyś w SentiOne próbowaliśmy wyceniać wszystko w godzinach. Programista z 10-letnim doświadczeniem wyceniał funkcję na 4 godziny, junior na 16. Kto miał rację? Oboje! Bo godzina pracy doświadczonego dev’a to nie to samo co godzina stażysty. To kluczowa kwestia, którą łatwo zbagatelizować.

• Zespoły często mają tendencję do zaniżania estymacji, zwłaszcza jeśli czują presję. „Szybka poprawka - 2 godziny!”, a potem okazywało się, że to 2 dni… 🤦‍♂️

• Brak punktu odniesienia - jeśli nie masz porównania do podobnych, zrealizowanych już zadań, estymacja absolutna staje się zgadywanką. Ciężko jest trafić w „punkt”, gdy nie masz do czego się odnieść.

• Sugerowanie się innymi. Wszyscy wiemy, jak to jest, gdy ktoś rzuci pierwszą liczbę, a reszta zespołu - świadomie lub nie - podąża za nią. Mało jest wtedy miejsca na prawdziwą dyskusję i weryfikację.

2️⃣ Planning Poker

Planning Poker to prawdziwy klasyk w świecie zwinnego zarządzania. Wywodzi się z metodyk Agile, takich jak Scrum, i najlepiej sprawdza się w połączeniu z jednostkami relatywnymi, czyli dobrze znanymi story pointami.

Czym są wyceny relatywne (np. story pointy)? 

Wyceny relatywne, w przeciwieństwie do estymacji absolutnych (np. w godzinach), nie podają konkretnego czasu potrzebnego na wykonanie zadania. Zamiast tego, oceniają one złożoność ,niepewność i wysiłek potrzebny do wykonania zadania w odniesieniu do innych zadań.

• Wyobraź sobie, że masz trzy obiekty: piórko, cegłę i samochód. Nie wyceniasz ich w kilogramach (absolutnie), ale mówisz, że cegła jest cięższa od piórka, a samochód od cegły.

• Story pointy działają podobnie – 1 story point to „małe” zadanie, 8 to zadanie 8x większe od małego, a 21 to „bardzo duże” zadanie (większe 21x od małego zadania).

• Zespół musi najpierw ustalić wspólny punkt odniesienia, czyli zadanie o danej wartości story pointów, do którego będzie porównywał wszystkie inne. To pozwala skupić się na złożoności problemu,

Jak działa Planning Poker?

1. Każdy z graczy (zazwyczaj członkowie zespołu deweloperskiego) dostaje talię kart z liczbami, zwykle z ciągu Fibonacciego (np. 1, 2, 3, 5, 8, 13, 21). Same wartości to jest kwestia umowna – należy jednak pamiętać, że im większa wycena tym zazwyczaj bardziej niedokładna. Można też dorzucić karty specjalne, takie jak symbol nieskończoności (zadanie jest za duże, by je oszacować) czy filiżanka kawy (potrzebujemy przerwy!) ☕.

2. Jako Product Owner lub Product Manager, Twoim zadaniem jest przedstawić zespołowi zakres danego zadania oraz odpowiedzieć na ewentualne pytania.

3. Gdy wszystko jest jasne, na ustalony znak (np. „trzy-czte-ry!”) wszyscy gracze jednocześnie wykładają karty z wybranymi przez siebie wycenami.

4. Dyskusja i konsensus - jeśli wartości się różnią, osoby z najniższą i najwyższą wyceną uzasadniają swoje wybory. To jest moment na prawdziwą dyskusję, wykrycie brakujących informacji i wspólne zrozumienie zadania. Następnie powtarzamy rundę, aż dojdziemy do konsensusu. Czasem przyda się moderator, np. Scrum Master.

Moje obserwacje:

• ➕ Dzięki jednoczesnemu wyłożeniu kart, unikamy efektu „kotwicy” i narzucenia od razu kierunku przez doświadczonych deków

• ➕ Różnice w wycenach zmuszają zespół do głębokiej debaty nad zadaniem, co często prowadzi do odkrycia ukrytych ryzyk czy zależności.

• ➕ Zespół buduje wspólne zrozumienie zadania i jego złożoności

• ➖ Metoda może być czasochłonna, zwłaszcza przy dużych i skomplikowanych zadaniach, które wymagają wielu rund dyskusji. Widziałem źle sfacylitowane sesje, które ciągnęły się godzinami!

• ➖ Mniej doświadczeni developerzy mogą odczuwać presję podczas dyskusji, by dostosować się do opinii bardziej doświadczonych kolegów. Ważna jest rola moderatora, który zadba o bezpieczną atmosferę.

• ➖ Z racji wykorzystania estymacji relatywnej, zespół potrzebuje wspólnego punktu odniesienia (bazowego zadania), do którego będzie porównywać resztę. Wypracowanie tych punktów odniesienia, które pozwala na szybką wycenę zwykle trochę trwa w zespole.

3️⃣ Team Estimation Game

Team Estimation Game to metoda, która również może wykorzystuje story pointy. Natomiast jej najważniejsza idea polega na tym, że staramy się wspólnie zadania posortować od najmniejszego do największego.

Sama metoda wymaga nieco przygotowania, ale potrafi być bardzo angażująca i budować wspólne zrozumienie w zespole.

Jak działa Team Estimation Game?

1. Drukujesz wszystkie zadania, które mają zostać oszacowane, oraz karty z wartościami liczbowymi reprezentującymi zakres możliwych wycen (np. od 1 do 21).

2. Uczestnicy gry, mają za zadanie uporządkować wszystkie zadania 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.

   1. Pierwszy gracz bierze pierwszą kartę ze stosu, czyta ją na głos i kładzie na środek stołu.

   2. Drugi gracz bierze kolejną, czyta i może wykonać jeden z dwóch ruchów - położyć kartę na dole (mniejsza pracochłonność) lub na górze (większa pracochłonność) karty, która już znajduje się na stole, jednocześnie uzasadniając swoją decyzję.

   3. Kolejni gracze mają do dyspozycji te same ruchy - mogą wziąć następną kartę ze stosu i ułożyć ją w odpowiednim miejscu na liście lub zmienić położenie jednej z kart znajdujących się już na stole. Oczywiście dalej trzeba uzasadnić swoją decyzję.

   4. Gra toczy się do momentu rozłożenia wszystkich kart ze stosu. Jeżeli wśród wszystkich graczy zapanuje zgoda, przechodzi się do ostatniego etapu.

3. Celem ostatniego etapu jest ułożenie kart w grupy, którym przypisuje się wspólne wyceny.

   1. Na początku kartę reprezentującą najmniejszą możliwą wycenę np. 1 umieszcza się obok pierwszej karty po lewej stronie (najmniejsza pracochłonność).

   2. Następnie pierwszy gracz otrzymuje kartę z następną możliwą wartością estymaty np. 2 i wybiera dla niej miejsce „w szeregu”. Każdy następny gracz albo bierze kolejną kartę z estymacją, albo zmienia pozycje dowolnej karty znajdującej się już na stole (dotyczy to zarówno kart z zadaniami, jak i tych reprezentujących wyceny).

   3. Gra toczy się do momentu, kiedy uda się pogrupować wszystkie zadania w pionowe kolumny. Nie wszystkie karty z wycenami muszą zostać ostatecznie wykorzystane, najważniejsze jest osiągnięcie konsensusu

Moje obserwacje:

• ➕ Jest to bardziej swobodna i interaktywna metoda, która angażuje cały zespół. Widziałem, jak zespoły, które nie przepadały za estymacją, wciągały się w grę.

• ➕ Każdy może zabrać głos i przedstawić swoje uzasadnienie, co prowadzi do bogatszej dyskusji.

• ➕ Czasem łatwiej najpierw posortować zadania i dopiero potem nadawać i wyceny (w planning pokerze tego nie ma).

• ➖ Czasami dyskusje mogą się zapętlić, a zespół ma trudności z osiągnięciem konsensusu, co prowadzi do frustracji. To się zdarzało w Rocket Studio przy bardziej skomplikowanych projektach.

• ➖ Bez dobrego moderatora sesja może się przedłużać w nieskończoność.

  ➖ Wymaga sporo przygotowania - potrzeba wydrukowania kart i ułożenia ich na stole.

Podsumowanie

Podczas mojej codziennej pracy jako Head of Product, czy Product Manager, doszedłem do jednego wniosku: nie ma jednej idealnej metody estymacji. Każda z nich ma swoje wady i zalety, i każda sprawdzi się w innym kontekście. To trochę jak wybór odpowiedniego narzędzia do konkretnego zadania - młotek do gwoździ, śrubokręt do śrub.

• Dla długoterminowych planów (Epiki, Inicjatywy): Często używam estymacji absolutnej na bardzo wysokim poziomie, ale z dużą dozą ostrożności. To raczej „T-shirt Sizing” (S, M, L, XL) niż precyzyjne godziny. Daje to ogólne pojęcie o skali, ale nie wiążę się z konkretnymi datami.

• Dla sprintów i precyzyjnych zadań: Moim faworytem jest zdecydowanie Planning Poker. Po latach doświadczeń, widzę, że ta metoda wymusza najważniejsze - dyskusję i wspólne zrozumienie zespołu. Nie raz uratowało nas to przed błędnymi założeniami.

• Gdy zespół jest nowy lub potrzebuje „rozruszania”: Team Estimation Game jest świetny, aby zespół się zintegrował i nauczył relatywnego myślenia o złożoności. To fajna, angażująca gra, która buduje zaufanie.

Pamiętaj, że estymowanie to nie tylko technika, to przede wszystkim proces komunikacji i budowania wspólnego zrozumienia w zespole. Im lepiej rozumiecie, co i dlaczego budujecie, tym dokładniejsze będą Wasze oszacowania.

Mam nadzieję, że ten deep dive pomoże Ci w lepszym zarządzaniu produktem i uniknięciu pułapek związanych z estymacją. Daj znać w komentarzach, jakich metod używasz i co sprawdza się u Ciebie najlepiej!