Zaokrąglanie szacowania Story Points

Coachingowe teksty o synergii mówią, że jeden plus jeden czasami daje więcej niż jeden. Zwinne Story Pointy mówią, że dzieląc wymaganie za 13 punktów, możemy otrzymać na przykłąd trzy wymagania, każde warte 5 SP. Problem jednak pojawia się, gdy połowa zespołu mówi „3”, a druga połowa „5”.

 

Przypowieść o motorówce

Omawiając szacowanie względne w Story Points, zacząłem ostatnio opowiadać przypowieść o motorówce. Dzięki niej staram się przemycić jedną bardzo ważną rzecz, dotyczącą wspólnego podejmowania decyzji o wielkości danego wymagania. Kto wie, czy nie najważniejszą.

Wyobraźmy sobie, że jesteśmy w porcie i chcemy popłynąć motorówką na pobliską wyspę. Chcemy też z niej wrócić. Wiemy, jak wygląda nasz pojazd, jaki ma silnik oraz ile osób zabieramy. Chcemy wspólnie ustalić, jak duży kanister ze sobą zabrać, żeby spokojnie popłynąć i wrócić. Żeby odpowiedzią nie było „jakoś się przemęczymy, weźmy największy”, przyjmijmy, że zapłacimy za tyle paliwa, ile się mieści w zbiorniku.

Jeżeli połowa osób mówi, że powinniśmy wziąć kanister o wielkości „5”, a druga połowa, że wystarczy nam „3”, to zupełnie bez sensu jest uśrednić tę wartość do „4”. Po pierwsze, nie mamy takiego kanistra (1, 2, 3, 5, 8, 13, 21…). Ale po drugie, trzecie i kolejne – z punktu widzenia połowy zespołu „3” spowoduje, że utkniemy w drodze powrotnej. Dodatkowo, druga połowa naszej dzielnej załogi nie chce marnować pieniędzy na tankowanie „5-tki” i uważa, że branie na pokład tak dużego zbiornika to przesada.

Tu nie ma miejsca na uśrednianie, tu musi pojawić się konsensus. Różnica zdań jest fundamentalna i mówi o tym, że inaczej rozumiemy spalanie, dystans, obciążenie naszej łódki, itd. Gdzieś się rozminęliśmy w założeniach, w związku z czym jakoś (patrz: refinement) musimy tę wiedzę uspójnić.

 

Jak to jest z tym szacowaniem

Oczywiście, jak już zaczniemy pływać tą łódką w tę i z powrotem z różnym obciążeniem i na różnych dystansach, nauczymy się szacować lepiej. Ale ciągłe zmiany prądów, zafalowania, składu załogi, wagi bagażu, itp. powodują, że nie jest to proste wyliczenie wprost. Jeszcze trudniej jest oczywiście szacować skomplikowaną pracę, najczęściej związaną z wytwarzaniem oprogramowania.

I nie ma tu znaczenia czy używamy Story Points, man-days czy czegokolwiek innego. Naszym celem nie jest znalezienie wartości, z którą wszyscy są względnie okej, tylko oszacowanie pracochłonności przy pewnych warunkach znanych i rozumianych przez wszystkie osoby, które później będą dane wymaganie realizowały. Zapewnienie takiego samego zrozumienia jest często ważniejsze niż wyznaczona wartość oszacowania.

Niestety, jak pokazaliśmy w filmie „Planning Poker – robisz to źle„, wiele osób zupełnie nie zwraca uwagi na to, co konkretnie ma nam przynieść nasze zwinne szacowanie. Rozprawialiśmy się tam z typowymi błędami, które najczęściej są popełniane przy okazji szacowania tą techniką. Jednym z nich, takim który napotykamy na każdym kroku, jest właśnie uśrednianie. Dwie osoby dały „3”, dwie „5”, a jedna „8”. Średnia wychodzi 4,8, więc zaokrąglamy to do „5” i mamy szacowanie z głowy.

Tylko, jak już dobrze wiemy z przypowieści o motorówce, takie wyniki mówią nam, że ktoś uważa, że z „5-tką” nie dopłyniemy.

 

Skąd się to wszystko wzięło?

Nie mam pojęcia, dlaczego tak powszechne są wspomniane pomyłki przy szacowaniu. Widzę jednak dwóch potencjalnych winowajców. Jeden to oczywiście brak właściwej wiedzy od samego początku stosowania danej techniki. Ot, pojawił się jakiś Agile Coach albo Scrum Master i „kazał” szacować w Story Pointach. A bez wiedzy o tym, czym one są i co tak naprawdę reprezentują, prosimy się o kłopoty.

„Co za różnica, man-day czy Story Point. Te drugie to po prostu zaokrąglone MD.” Z takiego właśnie błędnego pojmowania idei stojącej za szacowaniem względnym rodzą się problemy. Bo tu nie tylko sama wartość jest istotna, ale też to, co ona reprezentuje i jak powinna być interpretowana. Niestety, zrozumienie tego, co to jest i z czym to się je, jest niska.

Robimy co możemy na naszych szkoleniach agile, starając się przekazać rzetelną wiedzę na temat tego kiedy warto i jak stosować szacowanie względne w punktach. Niestety, nie mamy wpływu na to, co się dzieje po szkoleniu. I tutaj często pojawia się drugi winowajca. Są nim używane później narzędzia.

 

Te okropne narzędzia

Wiele narzędzi używanych do szacowania w Story Pointach, jak chociażby popularne Hatjitsu, nie tylko wylicza średnią, ale nawet odchylenie standardowe. Po co? Zapewne dlatego, żeby nie był to prosty „tool”, który zasadniczo tylko odkrywa karty w jednym momencie. Być może autor chciał, żeby robił on coś więcej. Niestety, dzięki temu mamy ludzi, którzy coś tam jeszcze pamiętają ze szkolenia, ale dostają prosto w twarz wyliczoną średnią. Uznają więc, że to jest ta wartość, którą mają użyć.

Jeszcze gorzej sytuacja wygląda u tych, którzy żadnej wiedzy wcześniej nie zdobyli, tylko używają narzędzia „na czuja”.

Nie tak dawno temu w agile’owym światku głośno było o tym, że kolejna wersja Jiry wprowadziła Story Pointy z dokładnością do wartości dziesiętnych. Przeczy to wszystkiemu, co SP powinny wyrażać. Tylko trudno się ludziom dziwić, że skoro jakaś funkcja jest dostępna, to z niej korzystają. „Przecież autorzy najpopularniejszej aplikacji do obsługi zwinnych przedsięwzięć wiedzą, co robią.” Wiedzą, ale nie ma to nic wspólnego z agile’owym ideami, tylko z oczekiwaniami użytkowników.

Nie używajmy narzędzi, nie wiedząc do czego mają służyć i/lub nie mając podstaw teoretycznych. Żeby wyręczać się maszynami i oprogramowaniem, warto mieć pewność, że w razie czego będziemy w stanie zrobić coś samodzielnie lub przynajmniej sprawdzić wyniki. Nie używajmy też technik, jeśli dobrze ich nie rozumiemy i nie mamy pewności, że stosujemy je poprawnie. Zapytajmy albo przynajmniej poszukajmy instrukcji na własną rękę. Pomocne materiały bez problemu znajdziecie na naszym blogu i kanale YouTube.

Tomasz Dzierżek

18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: