Wprowadzenie
W dyskusjach o planowaniu projektów IT regularnie wraca pytanie, czy lepiej estymować pracę w story points, czy w man-days. Dla części zespołów story points są naturalnym narzędziem do planowania sprintów i przewidywania tempa delivery. Dla biznesu z kolei bardziej intuicyjne bywają man-days, bo łatwiej powiązać je z budżetem, pojemnością zespołu i harmonogramem. Problem polega na tym, że obie metody służą trochę innym celom, a ich mieszanie bez zrozumienia kontekstu prowadzi do błędnych decyzji.
W praktyce nie chodzi o wybór jednej „lepszej” metody na zawsze. Ważniejsze jest zrozumienie, co dokładnie chcemy zmierzyć, kto będzie odbiorcą estymacji i jaką decyzję mamy na jej podstawie podjąć. Story points i man-days mogą się uzupełniać, ale tylko wtedy, gdy zespół jasno komunikuje ograniczenia każdej z tych miar.
Problem biznesowy
Z perspektywy biznesowej najczęściej potrzebne są odpowiedzi na trzy pytania: ile to potrwa, ile będzie kosztować i co realnie zmieści się w ustalonym terminie. Man-days wydają się wygodne, bo bezpośrednio sugerują nakład pracy. Jeśli zespół mówi, że coś zajmie 20 man-days, interesariusze od razu próbują przeliczyć to na dwie osoby przez dwa tygodnie. Taki skrót myślowy bywa kuszący, ale ignoruje kontekst: dostępność ludzi, narzut komunikacyjny, zależności techniczne i poziom niepewności.
Z kolei story points bywają krytykowane przez biznes za to, że nie przekładają się bezpośrednio na koszt. Jeśli zespół mówi o 40 punktach, ale nie umie wyjaśnić, jak to wpływa na termin i budżet, menedżerowie mogą odnieść wrażenie, że dostają abstrakcyjną metrykę. Problem nie leży jednak w samej metodzie, tylko w niewłaściwym użyciu. Story points mają wspierać przewidywanie tempa pracy zespołu, a nie zastępować rozmowę o kosztach.
Wyjaśnienie techniczne
Story points mierzą względną złożoność pracy. Zespół porównuje zadania między sobą, uwzględniając zakres, ryzyko, niepewność i wysiłek implementacyjny. Dzięki temu można łatwiej zachować spójność planowania nawet wtedy, gdy różne osoby pracują w różnym tempie. Kluczowe jest tu pojęcie velocity, czyli liczby punktów dostarczanych przez zespół w kolejnych iteracjach. Jeżeli velocity jest stabilne, story points dobrze wspierają krótkoterminowe planowanie.
Man-days działają inaczej. To próba opisania pracy w jednostce czasu, zwykle odpowiadającej jednemu dniowi pracy jednej osoby. Taka metryka jest bardziej bezpośrednia, ale też bardziej podatna na fałszywą precyzję. W praktyce zadanie oszacowane na dwa dni może zająć cztery, jeśli pojawi się dodatkowa integracja, niejasne wymagania albo nieprzewidziane poprawki. Man-days sprawdzają się najlepiej tam, gdzie zakres i sposób realizacji są już dość dobrze poznane.
Technicznie najważniejsze jest to, by nie traktować story points jak ukrytych godzin. Jeżeli zespół mówi, że jeden punkt odpowiada pół dnia pracy, story points tracą sens i stają się tylko inną nazwą dla estymacji czasowej. Znika wtedy korzyść płynąca z porównywania względnej trudności zadań, a zespół wraca do tego samego problemu: udawania, że zna dokładny czas wykonania, mimo że nie zna jeszcze wszystkich warunków realizacji.
Przykład praktyczny
Wyobraźmy sobie zespół rozwijający aplikację SaaS dla działów HR. W backlogu pojawiają się trzy elementy: eksport raportów do CSV, konfiguracja ról użytkowników oraz integracja z zewnętrznym systemem SSO. Eksport raportów jest dobrze znany i podobny do wcześniejszych funkcji. Role użytkowników są średnio złożone, ale dotykają wielu ekranów. Integracja SSO wydaje się niewielka z punktu widzenia UI, jednak niesie ryzyko związane z dokumentacją dostawcy i bezpieczeństwem.
W story points zespół może ocenić eksport na 2 punkty, role na 5 punktów, a SSO na 8 punktów, bo ryzyko i niepewność są wyraźnie większe. W man-days ktoś z biznesu mógłby intuicyjnie założyć, że integracja SSO zajmie mniej niż role, bo „to tylko logowanie”. Właśnie tutaj story points lepiej pokazują, że nie chodzi wyłącznie o liczbę ekranów czy linijek kodu. Z drugiej strony, kiedy zespół ma już dane historyczne, może przeliczyć swój sprint capacity i wyjaśnić biznesowi, ile punktów zwykle mieści się w jednej iteracji oraz jaki to ma wpływ na termin i koszt.
Najczęstsze błędy
Jednym z najczęstszych błędów jest próba używania jednej metody do wszystkiego. Story points są słabe jako bezpośredni język do rozmowy o budżecie z zarządem, jeśli zespół nie ma stabilnego velocity. Man-days są z kolei ryzykowne jako jedyna miara planowania sprintów, gdy backlog jest pełen niejasności i zadań badawczych. Innym błędem jest porównywanie velocity między zespołami. Punkty są lokalne dla konkretnego zespołu i nie powinny służyć do budowania rankingów wydajności.
Problemem bywa również nadmierna szczegółowość. Jeśli zespół próbuje rozbić każdy task na ułamki dnia lub na bardzo precyzyjne punkty, proces planowania staje się kosztowny i niewiele wnosi. Błąd pojawia się też wtedy, gdy biznes oczekuje, że estymacja w man-days będzie gwarancją terminu, zamiast traktować ją jako najlepsze dostępne przybliżenie oparte na znanym zakresie.
Rekomendacje
W praktyce warto używać story points do planowania iteracyjnego i porównywania względnej złożoności zadań wewnątrz zespołu. To dobre narzędzie tam, gdzie ważne jest tempo dostarczania, a wymagania ewoluują. Man-days sprawdzają się lepiej na poziomie ofertowania, forecastu lub modelowania pojemności, ale pod warunkiem, że zakres został wcześniej doprecyzowany i obszary ryzyka są jawnie opisane.
Najbardziej użyteczny model to często połączenie obu perspektyw. Zespół planuje backlog w story points, dzięki czemu zachowuje spójność pracy operacyjnej. Następnie, na podstawie historycznego velocity i składu zespołu, tłumaczy to na szacunkowy horyzont czasowy oraz widełki kosztowe. Taki proces daje biznesowi bardziej zrozumiały obraz, nie niszcząc zalet metody zwinnej po stronie delivery.
Podsumowanie
Story points i man-days nie są konkurencyjnymi religiami, ale narzędziami do różnych rodzajów decyzji. Story points pomagają zespołowi ocenić względną złożoność i planować pracę w warunkach zmienności. Man-days pomagają komunikować pojemność, budżet i przewidywany nakład w języku bardziej zrozumiałym dla biznesu.
Najważniejsze jest to, by jasno określić cel estymacji i nie oczekiwać od jednej metryki odpowiedzi na wszystkie pytania. Jeśli zespół rozumie różnicę między tymi modelami i potrafi przekładać je na decyzje produktowe, planowanie staje się bardziej transparentne, a ryzyko nieporozumień wyraźnie spada.