Zamiast korzystać z „tradycyjnych” jednostek, takich jak dni robocze, coraz więcej zespołów przechodzi na szacowanie za pomocą Story Pointów. Dlaczego to jest ważne i jak to zrobić? Oto kilka kluczowych kwestii, które warto rozważyć podczas przejścia z Man Day na Story Points.
MD vs SP
Story Points to jednostka używana do określania trudności i rozmiaru zadań. Man Day (manday, dzień roboczy) określa nam tylko i wyłącznie czas. To jest podstawowa różnica, chociaż nie jedyna. Jej konsekwencją jest fakt, że SP to miara względna, która opisuje tylko i wyłącznie stosunek (proporcję) pomiędzy wymaganiami. Jako taka nie nadaje się do porównywania, ale też i do paru innych rzeczy (m.in. do szacowania konkretnych tasków).
Manday stosujemy raczej w projektach, umowach i kontraktach, bo najczęściej stoją za nimi pieniądze. Story Points stosujemy w zespołach, gdzie szacują Deweloperzy, bo to oni będą wykonywać potem tę pracę. W ten sposób unikamy nacisku związanego z dniem roboczym jako jednostką czasu. Nikt nie musi się obawiać, że zostanie ukarany za wymaganie, które okazało się trudniejsze niż początkowo przewidywano.
Skoro te miary służą do różnych rzeczy, to może w ogóle nie powinniśmy sobie zawracać głowy, tylko używać ich w różnych miejscach przez różne osoby?
Ryzyka systemu dwóch wartości
Użycie Man Day’ów do oszacowania zadań bądź całych projektów oraz Story Pointów do oszacowania wymagań to hybrydowe podejście, które jest stosowane w niektórych przypadkach.
Przede wszystkim warto wspomnieć o tym, że Man Day’e się sumują. To znaczy, że możemy podzielić projekt na kawałki, oszacować każdy z nich, a potem zsumować i (w teorii) wartość będzie właściwa. Możemy pokazać zależności między zadaniami, narysować wykres Gantta, zarządzać nimi na poziomie matematycznym.
Story Pointy się nie sumują w ogóle bądź średnio. Korzystanie ze skali opartej o ciąg Fibonacciego powoduje, że w przypadku dużych liczb nieokreśloność jest ogromna. Bo sumując wymagania za 21, 21 i 13 punktów otrzymamy 55. Ale sumując 21, 8, 8 – również dostaniemy 55. Im dalej tym gorzej, bo przerwy robią się coraz większe.
Dni robocze to czas. Czas jaki jest, każdy widzi. Jeśli szacujemy cokolwiek w czasie, to nie musimy potem tego planować – co najwyżej stworzyć harmonogram. Story Pointy są relatywnym miernikiem złożoności i wysiłku, nie mającym bezpośredniego odniesienia do czasu. Mają one oczywiście jakieś-tam przełożenie, ale stosując obie miary kręcimy na siebie bat.
Używając MD i SP do różnych celów – do rozmów z klientem i do wewnętrznego planowania mamy dwa złe wyjścia. Albo musimy szacować wszystko podwójnie, albo jedni ludzie używają jednej miary (np. Project Managerowie), a inni (Scrum Team) drugiej. Tylko chyba wszyscy czujemy, że to prędzej czy później eksploduje.
Konwersja Man Day na Story Point
Przejście z Man Day’ów na Story Pointy może wymagać pewnej pracy, jest bardzo często pożądany i występuje w sytuacje, w której backlog mamy już wyszacowany w MD, a chcemy przejść na te „zwinne” Story Pointy. Tu nie da się ukryć, że trzeba zacząć od edukacji. Zacznij od tego, żeby Twój zespół dokładnie zrozumiał, czym są Story Pointy i jakie są zasady szacowania.
W drugim kroku zidentyfikuj wymagania, które już wykonaliście i które mają określone oszacowania w dniach roboczych. Porównaj te oszacowania z nowymi szacunkami w Story Pointach, aby zrozumieć, jakie są ich relacje. Następnie wyrzuć wszystko i mając wiedzę „z porównania” zacznij szacować w Story Pointach. Wybierz typowe bądź najmniejsze wymaganie, ustaw je jako punkt wyjścia i przyrównuj pozostałe do niego. Im szybciej zapomnimy o Man Day’ach tym lepiej.
W temacie poszukiwania informacji o konwersji, sięgneliśmy nawet do ChataGPT, który odpowiedział dość jasno (jak na niego):
„Obliczanie [Story Pointów] na podstawie dni roboczych może być trudne, ponieważ obie te metody szacowania mają różne założenia i jednostki miary. Jednakże, jeśli chcesz spróbować dokonać takiego przeliczenia, można to zrobić w przybliżeniu, ale warto pamiętać, że będzie to tylko przybliżenie, a nie dokładne przeliczenie.”
Nie ma tu co ściemniać – nie dokonujemy konwersji w sposób matematyczny, „przedziałami”, czy jakkolwiek inaczej. Utracimy w ten sposób nie tylko względność oszacowań, ale i ujęcie kryteriów innych niż sam czas! Jeśli chcemy przejść z jednej miary na drugą, musimy zrozumieć, że są one inne i działają w inny sposób. I bardzo często służą do innych celów.
Jeżeli nawet ChatGPT zapytany o ten temat odradza jakąkolwiek matematyczną konwersję, to znaczy, że coś z tym musi być nie tak. Jeżeli chcemy szacować wymagania, to wybierzmy jakąś miarę i się jej trzymajmy. A jeżeli idziemy w stronę systemu dwóch wartości, to zadbajmy o to, aby poszczególne oszacowania się nie mieszały i nie miały na siebie wpływu. Tylko trudno się w ten sposób oszukiwać, bo będą. Gdzieś ktoś w końcu przyjdzie i zapyta „Mówicie, że zostało wam jeszcze 50 Story Pointów, ale klient zapłacił za 100 Man Day’ów. To ile punktów to jeden MD?”
Hej Łukasz,
słusznie zauważyłeś, że niestety nie ma jednej, skutecznej, jasnej i prawidłowej metody przejścia z MD na SP. Sam zmagam się z tym tematem aktualnie i ciągle zastanawiam się czy dobrze go ugryzłem.
Tak jak wspomnieliście z Tomaszem w filmie, najczęstszym powodem zmiany sposobu szacowania jest to, że po prostu nasze szacunki totalnie rozmijają się z rzeczywistością, tak też było u mnie w zespole.
Pracujemy w środowisku gdzie planujemy kadencyjnie i powinniśmy co kwartał być w stanie oszacować nasze capacity i na tej podstawie dobrać PBI nad którymi będziemy pracować w nadchodzących kilku sprintach ( pewnie w tym momencie domyślasz się o jakim frameworku mówię – myślę, że w tym momencie możemy to przemilczeć).
Wraz z zespołem po analizie backlogu oraz naszego velocity stwierdziliśmy, że szacowanie w dniach nie daje nam żadnych korzyści i nigdy nie jesteśmy nawet blisko prawdy. Dlatego zdecydowaliśmy się, że porozmawiamy na czym polega szacowanie relatywne. Dotknęliśmy tematów typu, że nie skupiamy się tylko na czasie, tylko na wysiłku, zakresie, złożoności, niepewności, ilości zależności, poziomu wiedzy w zespole, ryzkach które mogą się pojawić i jakie będa miały konsekwencje. Stworzyliśmy nawet referencyjną historyjkę do której zaczęliśmy porównywać. Dla niektórych zmiana sposobu szacowania była prosta i zrozumiała, jednak część osób wciąż patrzyła tylko na wymiar czasowy.
Wtedy stwierdziłem, że jednak stworzę tabelkę która mapuje MD na SP, bo pomoże to reszcie przestawić myślenie. Mówisz, żeby kategorycznie tego nie robić, jednak moje doświadczenie pokazuje, że pomogło to niektórym osobom lepiej zrozumieć temat, jednak zanim podzieliłem się tą tabelką omówiliśmy dokładnie jak powinniśmy na nią patrzeć (żeby znowu nie wpaść w pułapkę, ze skupiamy się tylko na czasie). Poniżej przykład
Fikcyjny członek zespołu : „OK zrobiłbym to w sumie jeden dzień więc powinno to być 2SP, ale jednak muszę skontaktować się z zespołem A i omówić to rozwiązanie, jeśli wszystko zaakceptują to wciąż wymaga to dodatkowych testów i do tego Zenek wspomniał, że muszę być zgodny z normą ISO561123 więc biorąc to wszystko pod uwagę praca nad tą historyjką na pewno zajmie mi więcej czasu bo jest po prostu większa od mojego poprzedniego zadanie, więc niech to będzie 5SP.”
Czy to złe podejście? Nie unikniemy rozważań na temat czasu, i jednak takie mapowanie na początku może być pomocne dla osób opornych do relatywnego/abstrakcyjnego porównywania między sobą. Czy na samym końcu nie chodzi o to, żeby uzyskać cel którym w naszym wypadku jest stanie się bardziej przewidywalnym zespołem?
Czy to podejście zadziała? Okaże się za pare sprintów, myślę, że temat błednych oszacowań nie zniknie, bo to wciąz oszacowania grunt to zbudować wspólna miarę dla całego zespołu do szacowania.
A jak w takim wypadku podeszlibyście do oszacowania capacity zespołu, skoro nie możemy polegać na żadnych historycznych danych a jednak musimy podać jakieś szacunki biznesowi?
pozdrawiam Was serdecznie i dziękuje za wszelkie materiały i przemyślenia którymi się dzielicie.
Obserwuje Was od dawna, ale to dopiero pierwszy raz kiedy zdecydowałem się na napisanie komentarza. 🙂