Z Man Day na Story Points

To jeden z tych momentów, gdzie po nagraniu filmu czuję pewien niedosyt. To nie tak, że w filmie o tym jak przejść z Man Day na Story Points nie zawarliśmy wszystkich istotnych kwestii. Mam jednak przekonanie o sile słowa pisanego. Spróbujmy więc opisać przejście z MD na SP i zastanowić się, czy zawsze ma to sens?

 

MD2SP

Piękny nagłówek rozdziału. W dobie wszechobecnych skrótów może powinienem zastanowić się nad jego opatentowaniem. Całkowicie na serio, nie ma jednej metody opisującej skuteczny sposób przejścia z Manday na Story Points. Krótka kwerenda w Google również nie daje odpowiedzi na to pytanie. Nie dziwi więc fakt, że tak bardzo temat leży mi na sercu.

Film, o którym wspominam na wstępie tego tekstu to nasz ostatni vlog na Youtube:

Dodatkową przyczyną, dla której powstaje ten wpis są komentarze na #białkowym profilu na LinkedIn. Lubię, gdy ludzie “z branży” komentują nasze filmy. Te, które dotyczyły powyższego filmu krążyły wokół dwóch aspektów: ruchu #noestimates oraz potencjalnych problemów z rozliczeniem projektu wyrażonego w punktach. O ruchu #noestimates nie chcę pisać w tym wątku, zasługuje on na osobny wpis albo nawet kilka.

Zastanawiając się nad drugim z tematów naszło mnie pytanie – dla kogo właściwie jest wycena w Story Points i po co jej właściwie dokonujemy?

 

Rozliczenie projektu

Zgadzam się w 100% ze stwierdzeniem, że rozliczenie projektu wyrażonego w punktach czy innej mierze względnej jest drogą przez mękę. Czasem można by rzec nawet, że jest niemożliwe. Ale chyba nie po to przechodzimy na miary względne, nie po to chcemy wyceniać nasz backlog w ten sposób. Powinniśmy sobie odpowiedzieć przede wszystkim na pytanie, dla kogo właściwie są te wyceny?

Wyceny względne są definiowane przez i przeznaczone dla Deweloperów. To oni korzystają z wyceny poszczególnych elementów backlogu. Łatwiej im w ten sposób zaplanować swoje prace czy odpowiadać na pytania biznesu o termin dostarczenia funkcjonalności znajdującej się na liście wymagań.

Z punktu widzenia naszego przedsięwzięcia wycena dokonywana przez zespół nie musi być wykładnią dla budżetu projektu. Projekt jest budżetowany przed rozpoczęciem prac, czyż nie?

Jeśli założymy, że powyższe jest prawdą odwraca się nam kolejność budżetowania. To budżet wyrażony w pieniądzu, wartości bezwzględnej, będzie wpływał na ilość Story Points możliwych do wykorzystania. Oczywiście przeliczenia złotówek na punkty to jedno, a stałe urealnianie wartości 1 punktu to drugie. I tutaj właśnie jest trudność o której mowa w komentarzach. Czy jest to jednak coś, co powinno być głównym zainteresowaniem Deweloperów? Oni mają wycenić wymagania!

 

Techniki wyceny

O technikach wyceny pisaliśmy, jedną z nich, Planning Poker dość dobrze nawet omówiliśmy na naszym #białkowym kanale na Youtube. Nie powtarzając już napisanych słów powiem tylko, że wynikiem pracy nad wyceną wymagań ma być backlog ułożony od najprostszych do najtrudniejszych PBI a w dalszej kolejności wyceniony. Nie należy mylić powyższego z priorytetyzacją. To dwie osobne sprawy, które nie mają ze sobą wiele wspólnego.

Coś, co jest utożsamiane z technikami, o czym muszę wspomnieć to próba mapowania MD na SP. Wygląda to mniej więcej w następujący sposób:

Nie postępujmy w ten sposób! Powód jest co najmniej jeden, ale niezwykle ważny. Nie mamy żadnej pewności, że określając MD wzięliśmy pod uwagę wszystkie zmienne dotyczące wielkości szacowanego wymagania. Mówiąc o MD, 80% z nas będzie brało pod uwagę jedynie czas. A to jest największy błąd tego podejścia, którego chcemy przecież uniknąć szacując w miarach względnych. Musimy wziąć pod uwagę również inne zmienne, jak chociażby ryzyko. Ale czy da się je wycenić? Dokładnie oszacować i wyrazić w czasie?

 

Z Man Day na Story Points

Na samym początku zapytałem, czy przejście z MD na SP ma sens. Jeśli widzimy potrzebę zmiany naszego sposobu szacowania, odpowiedź brzmi: jak najbardziej. Jeśli wszystko jednak wygląda dobrze, a wyceny w Man Day’ach dokonywane przez Deweloperów są trafne (nie używam słowa dokładne) to nie ma potrzeby zmian. Zresztą, te wyceny w MD mogą być wykonywane względne. Są przecież robione z pewną dokładnością.

Jeśli jednak mamy problem z konsekwencjami niedotrzymywanych terminów lub rozliczani jesteśmy z roboczo-dni wskazanych na wymaganiu (bo przecież dokonaliśmy wyceny w gronie Deweloperów), sugeruję wykonanie kroku zbliżającego nas ku wycenom względnym. Co więcej, ten sam krok sugeruję w przypadku braku możliwości wyceny zmiennych niemożliwych do ujęcia w czasie.

A jak przejść z Man Day na Story Points? Cztery proste kroki znajdziecie w podlinkowanym filmie!

Łukasz Bręk

15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum. Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Click Here to Leave a Comment Below

Matt - 11 lutego 2021

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. 🙂

Reply
Leave a Reply: