Zadanie miało zająć dwa dni, a zajęło tydzień. Sprint zaplanowany na konkretną liczbę zadań kończy się z połową niezrobionej pracy. Klient pyta, kiedy będzie gotowa funkcja, a zespół podaje termin, w który sam nie do końca wierzy. To efekt słabej estymacji zadań - jednego z najtrudniejszych elementów pracy zespołowej, którego nikt nie uczy się formalnie, a każdy musi robić co tydzień.
Dobra wiadomość: estymacja nie musi być wróżeniem z fusów. Istnieją konkretne metody, które nie gwarantują stuprocentowej trafności, ale znacznie zmniejszają rozjazd między tym, co zespół zaplanował, a tym, co faktycznie się wydarzy.
W tym artykule pokażę, dlaczego estymacje tak często zawodzą, jakie metody estymacji zadań działają w praktyce i jak wprowadzić je w zespole bez tworzenia kolejnej biurokratycznej procedury.
Dlaczego estymacje zadań tak często się nie sprawdzają
Efekt nadmiernego optymizmu
Ludzie systematycznie zaniżają czas potrzebny na zadanie, zwłaszcza gdy myślą o nim w oddzieleniu od reszty pracy. Programista wyobraża sobie idealny dzień bez przerwań, spotkań i poprawek po code review - taki dzień rzadko się zdarza.
Brak uwzględnienia przerw i zależności
Estymacja "to zajmie cztery godziny" zwykle dotyczy samego pisania kodu, nie czasu na code review, poprawki, czekanie na odpowiedź od innej osoby czy testy. Te elementy potrafią podwoić rzeczywisty czas realizacji.
Dobrym przyzwyczajeniem jest pytanie podczas estymacji: "co jeszcze musi się wydarzyć, zanim to zadanie będzie naprawdę gotowe?". Najczęściej odpowiedź zawiera krok, o którym nikt nie pomyślał, mówiąc tylko o czasie pisania kodu.
Estymacja przez jedną osobę
Kiedy estymuje tylko jedna osoba, łatwo przeoczyć złożoność, którą zauważyłby ktoś inny z zespołu. Druga perspektywa często wychwytuje ryzyko, o którym estymujący nie pomyślał.
Dlaczego liczba osób estymujących ma znaczenie
Badania nad estymacją w zespołach programistycznych pokazują, że szacunki dwóch lub trzech osób, uśrednione po krótkiej dyskusji, są systematycznie trafniejsze niż szacunek jednej, nawet bardzo doświadczonej osoby. Różnica wynika z tego, że każda osoba zauważa inny fragment ryzyka - jedna pamięta podobny problem z przeszłości, druga widzi zależność od zewnętrznego systemu, o której pierwsza nie pomyślała.
Czym różni się estymacja od deadline'u
Estymacja to szacunek czasu potrzebnego na wykonanie pracy, oparty na dostępnej wiedzy. Deadline to termin ustalony często z powodów biznesowych, niezależnie od estymacji. Problem zaczyna się, gdy te dwie rzeczy są traktowane jako to samo - zespół estymuje zadanie na tydzień, a kierownictwo "ustala", że ma być gotowe za trzy dni, bez zmiany zakresu czy zasobów.
Estymacja powinna być punktem wyjścia do rozmowy o priorytetach, nie przeszkodą do obejścia. Więcej o ustalaniu priorytetów przeczytasz w artykule Priorytetyzacja zadań - sprawdzone metody.
Metody estymacji zadań
Story points
Zamiast podawać czas w godzinach, zespół ocenia względną złożoność zadania w punktach - na przykład w skali Fibonacciego (1, 2, 3, 5, 8, 13). Punkty nie odpowiadają bezpośrednio godzinom, ale po kilku sprintach zespół wie, ile punktów realnie kończy w jednym sprincie, co pozwala planować kolejne iteracje.
Ta metoda ma jedną przewagę nad estymacją w godzinach: trudniej oszukać samego siebie. Łatwiej przyznać, że zadanie jest "ósemką", czyli wyraźnie bardziej złożone niż typowe zadanie, niż zadeklarować konkretną liczbę godzin, która później zostanie potraktowana jako obietnica.
Planning Poker
Każdy członek zespołu niezależnie wybiera kartę z liczbą punktów dla danego zadania, a karty są odkrywane jednocześnie. Jeśli oceny się różnią, zespół krótko dyskutuje, dlaczego - często wychodzi na wierch szczegół, o którym część osób nie wiedziała. To prosta technika, która eliminuje wpływ pierwszej wypowiedzianej liczby na resztę zespołu.
Estymacja w godzinach lub dniach
Najbardziej intuicyjna metoda - zespół podaje, ile czasu zajmie zadanie, w jednostkach czasu. Działa dobrze przy dobrze znanych, powtarzalnych zadaniach, ale słabiej przy nowych, niepewnych obszarach, gdzie różnica między najlepszym i najgorszym scenariuszem jest duża.
T-shirt sizing
Zadania ocenia się w kategoriach S, M, L, XL, bez podawania konkretnej liczby. To szybka metoda przydatna na etapie planowania większego zakresu pracy, zanim zespół zacznie estymować szczegółowo poszczególne zadania.
Jak estymować zadania krok po kroku
Rozbij duże zadanie na mniejsze
Zadanie opisane jako "zbuduj system płatności" jest praktycznie niemożliwe do trafnej estymacji. Rozbicie go na mniejsze, konkretne kroki - integracja z dostawcą, obsługa błędów, testy - pozwala estymować każdy fragment z większą dokładnością, a sumy poszczególnych estymacji są zwykle trafniejsze niż jedna duża liczba.
Dobrym sygnałem, że zadanie jest wciąż za duże, jest sytuacja, w której zespół nie może podać estymacji bez słowa "to zależy" powtórzonego kilka razy. Im więcej takich niejasności, tym więcej sensu ma dalszy podział zadania, zanim ktokolwiek zacznie nad nim pracować.
Estymuj zespołowo, nie samemu
Krótka rozmowa zespołu przed estymacją zajmuje kilka minut, a wychwytuje założenia, które jedna osoba mogłaby przeoczyć. Nie musi to być formalna sesja Planning Poker - czasem wystarczy zapytać: "czy ktoś widzi w tym zadaniu coś, czego ja nie widzę?".
Uwzględnij niepewność
Zadanie, które zespół robił już wielokrotnie, można estymować z dużą precyzją. Zadanie dotykające nieznanego obszaru - nowej technologii, integracji z systemem, którego nikt wcześniej nie używał - wymaga dodatkowego bufora na niespodzianki, które prawie zawsze się pojawiają.
Porównuj z podobnymi zadaniami z przeszłości
Jeśli podobne zadanie zajęło ostatnio trzy dni, nowe zadanie o podobnej złożoności prawdopodobnie zajmie podobnie, niezależnie od tego, jak optymistycznie czuje się zespół na starcie. Przegląd wcześniejszych sprintów na retrospektywie jest dobrym momentem, żeby zebrać takie punkty odniesienia.
Przykład z praktyki
Zespół programistyczny estymował integrację z nowym dostawcą płatności na trzy dni, bazując na podobnej integracji wykonanej rok wcześniej. Podczas Planning Poker jedna z osób zauważyła, że tamta integracja korzystała z dobrze opisanego API, a nowy dostawca ma dokumentację, która w przeszłości okazywała się niekompletna u innego klienta. Zespół podniósł estymację do pięciu dni, dodając bufor na niespodzianki w dokumentacji.
Integracja faktycznie zajęła cztery dni - bliżej poprawionej estymacji niż pierwotnej. Gdyby zespół estymował zadanie pojedynczo, bez wymiany perspektyw, różnica między planem a rzeczywistością byłaby znacznie większa, co wpłynęłoby na cały harmonogram sprintu.
Najczęstsze błędy przy estymacji
Traktowanie estymacji jako obietnicy - estymacja to szacunek, nie zobowiązanie, a mylenie tych dwóch pojęć prowadzi do niepotrzebnej presji.
Estymowanie pod presją czasu - estymacja zrobiona w pięć minut przed spotkaniem rzadko jest dokładniejsza niż zgadywanie.
Brak rewizji estymacji po zmianie zakresu - jeśli zadanie się rozrasta, estymacja powinna się zmienić razem z nim, a nie zostawać przy pierwotnej liczbie.
Ignorowanie danych z przeszłości - zespół, który nie sprawdza, jak trafne były wcześniejsze estymacje, nigdy się w tym nie poprawia.
Jak Taskello pomaga przy estymacji zadań
W Taskello każde zadanie można opisać razem z szacowanym czasem realizacji i priorytetem, dzięki czemu cały zespół widzi na tablicy nie tylko co jest do zrobienia, ale też jak duże jest to zadanie. Przy planowaniu sprintu ułatwia to ocenę, czy lista zadań realnie zmieści się w dostępnym czasie, zamiast przekonywać się o tym dopiero w połowie sprintu.
Historia zamkniętych sprintów pozostaje widoczna w projekcie, więc zespół może wrócić do niej przy kolejnej estymacji i porównać nowe zadanie z podobnym, które już wcześniej zrealizował.
Podsumowanie
Estymacja zadań nigdy nie będzie idealna, ale nie musi być przypadkowa. Rozbijanie dużych zadań na mniejsze, estymowanie zespołowo, uwzględnianie niepewności i porównywanie z przeszłością znacznie zwiększają trafność szacunków.
Jeśli Twój zespół regularnie przekracza estymowany czas, zacznij od jednej zmiany: po zakończeniu sprintu porównaj estymacje z rzeczywistością i zapytaj, co spowodowało różnicę. Po kilku takich przeglądach estymacje same staną się dokładniejsze, bez wprowadzania żadnej dodatkowej procedury.
Trafniejsza estymacja przekłada się też na realniejsze planowanie sprintów - więcej o samym procesie planowania przeczytasz w kolejnym artykule o Sprint Planning, a o tym, jak ograniczyć liczbę zadań rozpoczętych jednocześnie w zespole, w artykule Zarządzanie czasem w zespole - praktyczne metody.