#019 – Estymowanie

Estymowanie to temat, który wzbudza dużo pytań oraz wątpliwości. W tym odcinku omawiamy czym jest estymowanie, przedstawiamy trzy podstawowe podejścia oraz zastanawiamy się nad sensem korzystania z estymat.

Zobacz wersję wideo i przeczytaj artykuł

Czym jest estymowanie i jaki jest sens korzystania z estymat? Poznaj trzy podstawowe podejścia do estymacji w Agile i przeczytaj o naszym praktycznym doświadczeniu w tej dziedzinie.

Estymowanie jest procesem wyceny lub jej ekstrapolacji, które mówi nam, jak wiele zasobów (pieniędzy, wysiłku, ludzi, czasu) musimy przeznaczyć na wykonanie danego projektu czy zadania.

W najbardziej klasycznym podejściu do estymacji odpowiadamy sobie na pytanie “ile zajmie Ci/Wam to pracy?”. Przykładowo Ile godzin lub dni potrzebujecie, żeby wykonać dane zadanie?

Drugie podejście bardziej skupia się na czasochłonności. Pytamy tu o to “kiedy to będzie?”. Nie interesuje nas, jak dużo pracy w tym zadaniu trzeba wykonać, chcemy znać datę, kiedy można odebrać wykonane zadanie lub kiedy dany projekt będzie skończony.

Jeśli chodzi o pierwsze podejście, to ten czas może przyjmować różne jednostki, zwykle mamy tu jednak na myśli tzw. “man-day”, które po polsku możemy przetłumaczyć na roboczo-dni. Jest to skrót myślowy odnoszący się do dnia pracy jednej osoby, a dla każdego może to znaczyć przecież zupełnie co innego. 

Stąd też zachęcamy Was do wykonania ćwiczenia i trakowania czasu kiedy faktycznie pracujecie. Może się okazać, że 7-8 godzin, które według Was były przeznaczone na pracę to tak naprawdę tylko 4,5, maksymalnie 6 godzin wydajnego działania. Pozostały czas to wszelkiego rodzaju przerwy na odpoczynek, odebranie telefonu czy przełączanie się między kontekstami różnych czynności. Przy pracy w biurze wchodzą tu też takie rozpraszacze jak np. szef, który przyszedł z jakąś ważną sprawą do przekazania, ktoś hałasował, ktoś wyciągnął na kawę. 

Dlatego, jeśli szacujecie pracę w sposób klasyczny, to przestrzegamy Was przed zakładaniem, że jeden dzień pracy to 8 godzin, a jeden tydzień pracy to pięć dni roboczych. Tak się dzieje w naprawdę idealnych warunkach pracy, które rzadko mają miejsce. Bierzcie to pod uwagę podczas określania, ile czasu Wam coś zabierze. 

Inną pułapką przy podejściu klasycznym jest prawo Parkinsona, które mówi, że praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie. Innymi słowy, jeśli powiecie, że coś zajmie Wam tydzień to tyle faktycznie zajmie, a może nawet więcej. Warto więc zastanowić się, czy nie rozważyć nieco mniejszych estymat, które w pewnym sensie dopingują nas i motywują do tego, żeby skupić się na tym, co jest najważniejsze i dostarczyć to w pierwszej kolejności.

Estymowanie w sposób klasyczny jest bardzo intuicyjne, co jest jego główną zaletą. Bardzo szybko uczymy się, ile konkretne typy zadań nam zajmują i ile jesteśmy w stanie wykonać w jeden dzień. 

Natomiast największy kłopot z klasycznym estymowaniem jest z tym że estymaty często zakładają tylko ten obszar pracy, który wiemy, że jest do wykonania. Nie biorą one pod uwagę tego, o czym nie wiedzieliśmy na etapie planowania, a co pojawi się niespodziewanie w czasie pracy. 

Drugą wadą tego podejścia jest taki, że w niektórych środowiskach pracy deklaracje ile coś nam zajmie czasu, są od razu zamieniane na obietnice wykonania za X czasu. W ramach zabezpieczenia się wycena ilości czasu jest zawyżana, aby mieć zapas na nieprzewidziane sytuacje i żeby wywiązać się z obietnicy. 

Z tego powodu w podejściu zwinnym bardzo popularne jest szacowanie relatywne (względne), w którym nie szacujemy w żadnych jednostkach stałych typu dni, czy godziny, ale poprzez porównywanie zadań, elementów Backlogu czy projektów między sobą. Nie musimy tu być bardzo precyzyjni, a czas potrzebny na oszacowanie pracy do wykonania zdecydowanie się skraca. 

W estymowaniu relatywnym stosujemy pewne rzędy wielkości, a zadania możemy pogrupować na małe, średnie i duże. Możemy też te grupy zamienić na pewne umowne jednostki jak np. Story Point’y. Z kolei mając dane historyczne, łatwiej będzie nam ocenić, ile w danym tygodniu jesteśmy w stanie wykonać zadań małych, średnich czy dużych. 

Dodatkową bardzo korzystną praktyką związaną z estymowaniem względnym jest to, że zazwyczaj takie estymowanie robi się całym zespołem. Jest to o tyle istotne, że różne osoby mogą mieć różne wyobrażenie odnośnie do konkretnego zadania. Jeśli zespół uwspólni wiedzę na temat tego, co jest do zrobienia i tego, co jest już zrobione, jakość estymaty wzrasta, a i cały zespół ma lepsze zrozumienie przedmiotu pracy.

Przestrzegamy Cię jednak przed pokusą porównywania estymat dwóch różnych zespołów. Nawet jeśli używacie takiej samej skali estymacyjnej, np. ciągu Fibonacciego, to wciąż możecie mieć całkowicie inaczej wykalibrowane jednostki oceny. Przykładowo oba zespoły ocenią zadanie na 3, ale dla jednego zespołu oznacza to 2 dni, a dla drugiego pół dnia. To jak porównywanie jabłek z bananami.

W ostatnim czasie obserwujemy też wzrost popularności nurtu “braku estymowania”. W związku z tym podzielimy się z Tobą przykładami, gdzie okazało się, że estymowanie nie jest zawsze niezbędne, aby zespoły odnosiły sukces.

Pierwszy z przykładów dotyczy zespołów spoza branży IT, wytwarzających produkty fizyczne lub oferujące usługi. We wszystkich, z którymi Jacek w ostatnim czasie współpracował (ok. 8), nie używano do planowania pracy estymat. Pomimo tego, że nie mieli oni przypisanego oszacowania do poszczególnych elementów na liście rzeczy do zrobienia, zespoły były w stanie planować pracę. Co więcej, ich precyzja planowania była na naprawdę imponującym poziomie.

Drugi z przykładów dotyczy zespołów, które startowały z perspektywy celów sprintów. Zespół zgodnie ustala, że zrobi wszystko, żeby ten cel zrealizować. Rozpoczynając pracę, przewiduje wykonać plan maximum z najbardziej rozbudowaną wersją rozwiązania. Jeśli jednak okazuje, że coś idzie nie tak, jak trzeba, to zespół po prostu w locie obcina zakres pierwotnego rozwiązania. Jest ono nadal akceptowane, nadal jest zgodne z Definition of Done, jest jednak trochę prostsze. Cały zespół wraz z Product Ownerem jest w stanie ocenić kilka Sprintów w przód, jakie kolejne cele osiągną. Co się de facto zamienia w taką roadmapę zorientowaną na cele. 

W tym drugim podejściu kluczowe są dwa czynniki. Przede wszystkim należy tu być nastawionym na osiągnięcie konkretnego rezultatu, a nie na to, żeby zrealizować jakieś konkretne zadania. Ponadto zespół musi posiadać kontekst biznesowy i z tej perspektywy też planować pracę. 

Podsumowując nasze rozważania o estymowaniu, to bez względu na to, jakie podejście zastosujemy, to najważniejsze jest zadanie sobie pytania: Po co nam to estymowanie? Co ono da zespołowi? Czy do czegoś się nam przyda? A może ktoś inny w firmie potrzebuje estymat?

Jesteśmy ciekawi jak w Twoim zespole lub w firmie podchodzi się do szacowania. Podziel się tym z nami w komentarzu.

W odcinku omawiamy następujące sposoby estymowania:

• Klasyczne – ile zajmie nam praca i na kiedy będzie gotowe
• Relatywne – poprzez porównanie
• Brak estymowania – najbardziej zaawansowane podejście

Wydarzenia, które wspominamy w nagraniu:

• 16-17 września w Warszawie Kuba poprowadzi warsztat „Prawdziwe przypadki Scrumowe„, oparty na trudny historiach zespołów scrumowych.

Daj nam znać co sądzisz o tym odcinku

• Napisz do nas maila na kontakt@porzadnyagile.pl
• Napisz na Twitterze https://twitter.com/PorzadnyAgile
• Napisz na FB fb.me/PorzadnyAgile
• Napisz komentarz kanale YouTube Porządny Agile
• Skomentuj na Soundcloud pod odcinkiem
• Napisz komentarz lub polub odcinek na YouTube

TRANSKRYPCJA

Kuba: Gdy poprosiliśmy Was o mity związane z Agilem i Scrumem Przemek  podsunął bardzo ciekawy wątek. Estymacja musi być w Story Pointach, a jeden Story Point to jeden dzień roboczy. To nas natchnęło do tego, że temat estymacji nadaje się na zupełnie osobny wątek, a może nawet i serię odcinków na temat estymowania brania tych estymat do planowania czy prognozowania pracy. W dzisiejszym odcinku skupimy się wyłącznie na tym, żeby wprowadzić temat estymowania, rozwiać trochę ten mit, który tutaj nam Przemek to podsunął, no i trochę po prostu zdefiniować czym jest estymowanie w podejściu zwinnym.

Jacek: To, co jest ważne, to że będziemy z Kubą dzisiaj mówić tylko o praktycznych metodach estymowania, z którymi zetknęliśmy się w trakcie naszej kilkunastoletniej przygody, no głównie ze światem IT, chociaż nie tylko. Tak więc robimy sobie tutaj taką przestrzeń na to, że nie pokryjemy wszystkich dostępnych na świecie naukowych metod estymowania. Wiemy, że one istnieją. Natomiast zależy nam, żeby ten podcast był maksymalnie praktyczny, więc skupimy się na tym, czego po prostu doświadczyliśmy w praktyce.

Kuba: Idąc konkretnie już do definiowania i klasyfikowania tego, jakie jest możliwe podejście do szacowania w pracy zespołów zwinnych, trzeba zacząć od podejścia klasycznego. I tu jest możliwe szacowanie poprzez odpowiedź na pytanie ile zajmie Ci to pracy. Tobie jako osoby wykonującej pracę w zespole albo Wam jako całemu zespołowi. Czyli na przykład. Ile godzin albo ile dni potrzebujecie, żeby wykonać dane zadanie lub jakąś daną większą rzecz. Drugie podejście bardziej skupiające się na czasochłonności, kiedy to będzie? Czyli nie do końca mnie interesuje jak dużo pracy w tym środku tego zadania trzeba wykonać, tylko po prostu podaj mi datę, kiedy mogę od Ciebie odebrać wykonane zadanie lub wykonaną jakąś cechę, czy idąc szerzej konkretny projekt, kiedy on będzie skończony.

Jacek: I to, co mówisz, to tak naprawdę może przybrać bardzo różne jednostki. No bo zwykle jak myślimy o czasie: to są minuty, godziny, dni, miesiące. Natomiast też bardzo popularnymi jednostkami są tak zwane nie wiem, czy po polsku na jakieś sensowne tłumaczenie może nawet roboczo dni. To jest przybliżenie. Jest po prostu skrót myślowy. Osoba wykonująca pracę przez jeden dzień, nie mówiąc o tym dniach to też taką jednostką, która próbuje uchwycić fakt, że dzień dla każdej osoby może znaczyć coś nie co innego pojawia się też jednostka idealny i zakładamy sobie, że pracujemy przez określoną ilość czasu w sposób absolutnie takiej niezakłócony Tom jednostka traktujemy jako jednostkę rejestracyjną Gdzie jest o tyle myślę Ważne, że takie ćwiczenia, do którego przeprowadzenia bym każdego zachęcił to jest sprawdzenie ile tak faktycznie czasu na pracę poświęconą w trakcie jednego dnia zapisanie sobie tych wyników i bardzo dużo tej kasy, którą tego służą i stworzenia następna podsumowanie Ile tak naprawdę tego czasu zablokowaliśmy tutaj na was na bazie własnego doświadczenia albo taką ewidencję prowadzone są źle Dobrze ponad rok na zaskakujące Dla mnie zawsze godzina, które co do zasady mam takie poczucie przeznaczyłem na pracę no to tak jest faktycznie pracę, którą sobie zanotowałem To sobie i raptem 4,5 na 6 godzin to naprawdę są takie bardzo wydajne dni natomiast o wszystkich przerwach są wczasowych No po prostu przerwa na to, żeby odpocząć Tak przerwa na posiłek ktoś zadzwoni Widzę, że muszę odebrać, ale też takie rozpędzanie się między zadaniami oraz czas przełączanie kontekstu tak więc podczas wbrew pozorom nie jest tak prosty do planowania, jakie może podobnie wydawać.

Kuba: Przenosząc tę kwestię na realia korporacyjne, no to oprócz takich potrzeb indywidualnych typu kawka, papierosek czy toaleta, to jeszcze dochodzą kwestie: a tu ktoś hałasował, a tu jakiś próbny alarm przeciwpożarowy, a tu szef przyszedł i miał bardzo ważną sprawę do przekazania. No jest to rozróżnienie na idealne dni, które zazwyczaj się nie mają szansy zrealizować albo mają szansę się zrealizować pod warunkiem, że siedzisz sam w pustym biurze. Idealne dni to jest takie dobre porównanie, nie wiem, czy macie takie doświadczenia, ale jeśli ktoś przyjdzie w długi weekend do pracy albo między świętami a Nowym Rokiem gdzie biuro jest absolutnie puściutkie, można się w całości skupić na pracy. Nie ma nikogo kto by przerywał. Wtedy faktycznie skacze produktywność i ta ocena ile mi to powinno zająć, a ile faktycznie zajęło jest dosyć zbieżna. Przenosząc to na jedną z pierwszych rekomendacji związanej z estymowaniem. Jeśli szacujecie pracę w sposób klasyczny, czy to oceniacie pracochłonność, czy czasochłonność. To zwłaszcza jeśli oceniacie i chcę cię wywieźć z pracochłonności czasochłonność. Czyli mając ocenę jak duże to jest, ile godzin, czy ile dni to nam zajmuje. Jeśli zsumujecie to, żeby ocenić na, kiedy będzie coś gotowe, to zdecydowanie uważajcie na to, żeby czasem nie policzyć, że jeden dzień pracy to jest osiem godzin, a jeden tydzień pracy to jest pięć dni roboczych. To jest po prostu bardzo mało wykonalne albo wymaga naprawdę super przychylnych warunków i zazwyczaj tak nie jest. W każdej firmie może to być różny przelicznik. Nawet pewnie w każdym zespole czy do każdej osoby, ale zdecydowanie warto sobie otwarcie powiedzieć ile efektywnie w praktyce wykonujemy pracy, żebyśmy czasami, nawet jeśli klasycznie szacujemy i robimy to bardzo sprawnie, to żebyśmy czasami później się nie przyjechali po prostu na dodawaniu i dzieleniu, bo za szybko, za wcześnie określimy jakiś termin czy deadline, czy obietnice spełnienia jakiegoś dopełnienia jakiejś daty, której po prostu nie damy rady.

Jacek: Pewną pułapką związaną z estymowaniem klasycznym jest prawo Parkinsona, które mówi, że praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie. Jak to wygląda w praktyce? Jeżeli planujecie sobie pracę i zapytanie o estymatę. Powiecie, że zajmie to Wam tydzień. No to najprawdopodobniej ta praca zajmie co najmniej tydzień, a może i więcej na skutek różnych nieprzewidywalnych na rzeczy. Jeżeli powiecie, że to jest dzień, no to co najmniej zajmie dzień. Plus jeszcze jest ta szansa, że może się jakby rozlać nieco poza tą pierwotną estymatę. Jakby wiedząc, że takie prawo istnieje warto się zastanowić czy aby nie byłoby sensowne rozważyć nieco mniejszych estymat, które w pewnym sensie dopingują nas i motywują do tego, żeby skupić się na tym, co w tej zaplanowanej pracy do wykonania tak naprawdę najważniejsze. I to dostarczyć w pierwszej kolejności.

Kuba: Podsumowując wątek definiowania podejścia klasycznego warto powiedzieć, że jest ono bardzo intuicyjne. Każdy, kto tylko chwilę popracuje już zaczyna łapać ile jakie zadanie mu zajmuje, tak w praktyce. Jak zaczyna pracę rano to czy da radę i ile da radę zrobić w dzień. I to jest intuicja. Natomiast największy kłopot klasycznym estymowaniem, zwłaszcza w projektach IT, z którymi nie mieliśmy dużo do czynienia, ale też rozszerzając to w rzeczach kreatywnych, w rzeczach, w których rozwiązywany jest złożony problem. To to, że estymaty często zakładają tylko ten obszar. To, co wiemy co jest do zrobienia, a nie są w stanie wyłapać tych rzeczy, których po prostu nie wiemy, no bo ich nie wiemy. Na przykład niedoszacowane są prace o jakiś taki aspekt typu, elementy, które trzeba było zmienić a nie nie zgadliśmy na etapie szacowania, że trzeba się za nie zabrać. Czy na przykład jakieś tematy, które trzeba było skonsultować? W skrócie szacowanie takie klasyczne często nie docenia tej dodatkowej pracy, która dopiero wyjdzie, gdy się faktycznie zabierzemy. Z tego powodu jest kłopotliwe. Drugi wymiar jest też taki, że te wyceny pracy do wykonania zwłaszcza w niektórych środowiskach pracy są od razu zamieniane na obietnice wykonania za X czasu. Czyli oceniłem na trzy dni. Czyli mój szef przyjdzie za trzy dni i będzie oczekiwał, że to wykonam. No i oczywiście wtedy rozpoczyna się pewna gra. Ja zawyżam o wycenę, żeby mieć ewentualny zapas na te nieprzewidziane sytuacje i na to, żeby wypełnić tę obietnicę, czy wręcz nawet zobowiązanie. Z drugiej strony szef dostrzega, że od czasu do czasu mam luzy. Widzi mnie trochę za często na fajce, czyli jestem niedociążony. Czyli może mnie przydusić o to, żeby te wyceny były niższe. Czasem tam dochodzi aspekt Klienta, który płaci za te dni. Nie dowierza, że jakieś tam kawałek systemu faktycznie zajmuje pięć dni albo pięć tygodni. Cała zabawa tak naprawdę rozpoczyna się od momentu, gdy te wyceny się zaczynają pojawiać i jak kto je interpretuje, jak to wykorzystuje i jak bardzo też podlegają pewnym presjom czy naciskom. Z tego powodu w podejściu zwinnym bardzo popularne jest szacowanie relatywne, w którym nie szacujemy w żadnych jednostkach takich stałych typu dni, czy godziny, czy tygodnie, czy właśnie „manday’e”, ale szacujemy poprzez porównywanie zadań między sobą, czy elementów Backlogu między sobą, czy nawet projektów między sobą. Jacek jak definiujesz szacowanie relatywne?

Jacek: No myślę, że to, co powiedziałeś to chyba jest mi najbardziej bliższe. Czyli, że estymujemy poprzez porównywanie. Takie podejście jest całkiem naturalnym dla ludzi sposobem decydowania i wybierania. No to zawsze przychodzi mi do głowy taki przykład, kiedy chcemy zdecydować się na jakiś abonament, jeśli chodzi o telefon. Nie musimy przyjść do dostawcy usługi i powiedzieć mu, że potrzebujemy 376 minut i 47 sms-ów, 1,5 GB Internetu. Raczej to wygląda w ten sposób, a przynajmniej wyglądało jak ostatnio nabywałem taką usługę. Dostajemy pewną liczbę pięciu pakietów na przykład. Każdy z tych pakietów zawiera w sobie jakoś tam określoną ilość minut, sms-ów, czy dostępu do Internetu. Z mojej perspektywy o wiele prościej jest zdecydować się szybko na jeden z tych pięciu pakietów. Wiadomo, że ten pierwszy to jest tak jak w ogóle prawie nie dzwonię. Ten maksymalny to jest dzwonię cały dzień. Bardzo szybko jestem w stanie powiedzieć pakiet numer dwa bądź pakiet numer trzy jest dla mnie OK. Bardzo podobnie funkcjonują sprzedawcy na przykład elektroniki w sklepach. Przychodzi niezdecydowany Klient, jeśli chodzi o np. telewizor. Dostaje najtańszy, średni, najdroższy. O wiele prościej poprzez porównanie, ten model ma to a ten model ma tamto jesteśmy w stanie podejmować decyzje. Ta logika, ona się bardzo fajnie przenosi ma estymowanie w sposób relatywny rzeczy, które mamy do zrobienia. Nie musimy być super precyzyjni i powiedzieć dokładnie ile czasu nam to zajmie, bo to jest dosyć czasochłonne. Poprzez porównanie jesteśmy w stanie powiedzieć, że to zadanie zajmie mniej więcej tyle, co tamto. To zajmie mniej. To zajmie więcej. Takie bardzo radykalne skrócenie czasu, który jest potrzebny na to, żeby wstępnie oszacować pracę do wykonania.

Kuba: To, co powiedziałaś o tym radykalnym skróceniu czasu to swoją drogą jest od razu jeden z pierwszych argumentów, żeby szacować względnie. Poza tymi unikaniami pułapek szacowania klasycznego, że szacowanie to dla niejednego zespołu czy dla niejednego specjalisty wchodzących w skład zespołu to jest po prostu męczarnia. Długo trwający proces, w którym próbujemy złapać precyzję w czymś to jest po prostu słabe do złapania. Szacowanie tutaj relatywne poprzez porównanie, poprzez swego rodzaju takie przybliżenie jest wystarczająco dobre. I tak się trochę pomylimy, ale przynajmniej nie marnujemy na to tak strasznie dużo czasu, jak może być pokusa, jeśli wpadniemy w taką pułapkę myślową. Jak odpowiednio długo usiądę nad szacowaniem to będzie bardzo precyzyjne i bardzo trafne szacowanie. Tu akurat w ogóle nie działa ta zasada i szacowanie względne bardzo pomaga, żeby po prostu się zatrzymać na którymś etapie. Być w przybliżeniu poprawnym. Na pewno się pomylimy, ale nie nie damy rady być wiele bardziej poprawnymi. Tak jak zdefiniowałeś szacowanie względne, to od razu już zawiera ten element też takiego pewnego podejścia. Stosujemy pewne takie grupy, czy wielkości, czy rzędy wielkości. Na zasadzie pakiet średni, duży, największy. Ja sam jak tłumaczkę komuś szacowanie względne, zaczynam jeszcze od takiego poziomu właśnie: Weź dwa zadania i porównaj je do siebie. Albo będą identyczne, czy wystarczająco podobnej wielkości, albo jedno z nich jest większe, a drugie mniejsze. Jeśli powtórzymy algorytmicznie kilka takich czynności to zaczynają nam się wyłaniać grupy zadań o podobnej wielkości. Jeśli mówię tu o zadaniach mam myśli konkretną jedną czynność, którą wykonuje dany członek zespołu, albo jakiś większy feature, czy jakiś element Backlogu produktu. Tak naprawdę nawet i na poziomie projektu też jest prawdziwe. Teraz porównując w parach jesteśmy w stanie wyłonić jakieś ewidentnie duże rzeczy, jakieś średnie, jakieś małe. W zależności od tego, jak dużo tych rzeczy jest, jesteśmy w stanie sobie też tych grup potworzyć więcej. Mamy tak naprawdę kilka ścieżek do wyboru. Możemy sobie zatrzymać się na poziomie tych grup i powiedzieć sobie: To jest małe, to jest średnie, to jest duże. To bardzo przypomina już konkretną praktykę która, która jest nazywana na przykład rozmiarami koszulek. Przyjmujemy skalę jak w koszulkach S, M, XL i tyle. Po prostu to są nazwy na pewne grupy wielkości. Możemy też te grupy zamienić na pewne umowne jednostki. Tu się pojawiają już wspomniane we wstępie Story Point’y, czyli umowne jednostki, wielkości, zadania. Czy umowne jednostki szacowania, które są specyficzne dla danego zespołu? Przez ten zespół w pewien sposób jakoś tam ustandaryzowane, czy rozumiane, czy wykorzystywane w praktyce. Te Story Point’y akurat dają podstawę, chociaż to też jednocześnie może być pułapka do tego, żeby być może je jakoś podsumować, policzyć, oceniać jakieś trendy z nimi związane.

Jacek: Możesz teraz pomyśleć tak jak Kuba opowiada o rozmiarach koszulek, czy jakieś tam po prostu, małe, duże, średnie. Możesz pomyśleć: No dobrze no to mają taką estymatę no to jak ja mogę powiedzieć na, kiedy coś będzie. Jest to bardzo proste. Wystarczy, że wiesz ile rzeczy, jakiego rodzaju jesteś w stanie zrobić w określonym odcinku czasu. Czyli wiesz na przykład, że średnio w ciągu dwutygodniowego okresu pracy jesteś w stanie zrobić dwa małe zadania, trzy średnie i jedno duże. Mając takie dane historyczne i wiedząc troszeczkę w przód ile pracy mamy do zrobienia jesteśmy w stanie powiedzieć, że ta konkretna praca będzie wykonana za dwa tygodnie. Tą na dzisiaj szacujemy, że będzie za cztery, no a ta to za dwa miesiące. Oczywiście im dalej wybiegamy w przód, ta szansa na to, że się mylimy i że coś się w międzyczasie zmieni też jakby na tej naszej liście zadań, że to się po prostu tak wydarzy.

Kuba: Dodatkową bardzo korzystną praktyką związaną z estymowaniem względnym jest to, że zazwyczaj takie estymowanie robi się całym zespołem. Można powiedzieć inaczej grupowo. Tutaj dochodzi wtedy taki aspekt, że różne osoby mogą mieć różne wyobrażenie tego zadania. Jeśli razem wspólnie cały zespół to przegada, przedyskutuję, uwspólni wiedzę uwspólni wiedzę na temat co jest do zrobienia, uwspólni wiedzę na temat tego, co jest już zrobione, co jest w systemie. Wychodzi bardzo fajna dyskusja, która z jednej strony trochę polepsza jakość tej estymaty, trochę uniezależnia tę estymatę od perspektywy pojedynczej osoby. Z drugiej strony po prostu cały zespół uwspólnia wiedzę i kontekst na temat tego, co jest do zrobienia. Jak można to zrobić. Uzyskujemy po prostu lepsze zrozumienie przedmiotu pracy przez zespół.

Jacek: To, co jeszcze jest istotnym aspektem, jeśli chodzi o estymowanie relatywne, to jest to, że tak jak czas możemy pokusić się, żeby porównywać. Czyli dwa zespoły oceniły, że jednemu zajmie praca tydzień, a drugiemu dwa tygodnie. W przypadku estymacji relatywnej nie jesteśmy w stanie takiego porównania zrobić. Powiedziałem możemy, bo pierwsza moja myśl jest taka, że oba zespoły mogą używać takiej samej skali estymacyjnej, na przykład ciągu Fibonacciego. Dwa zespoły i estymują swoją pracę przy użyciu tego ciągu. Jeżeli jeden zespół powiedział trzy, drugi też powiedział trzy, to możemy ulec pokusie, żeby stwierdzić okej. Wyceniły tę pracę tak samo. Nie jest to prawda z tego względu, że każdy zespół może zupełnie inaczej mieć wykalibrowane te jednostki. Dla jednego zespołu ta trójka to może patrząc na to, ile faktycznie im zajęła praca. Taka trójka to może być dwa dni, a dla drugiego zespołu trójka to jest praca na pół dnia. Tak więc nie jest to możliwe. To jest trochę jak porównywanie jabłek z bananami. To są jakby zupełnie inne rzeczy. Nie mówiąc już o przypadkach, gdzie jeden zespół używa skali na przykład Fibonacciego, czyli mamy cyfry. Inny zespół używa, tak jak Kuba wspomniał przed chwilą rozmiarów koszulek. Jak porównać trzynastkę z emką.

Kuba: Albo z siedmioma emkami.

Jacek: Jest to praktyka, znaczy nie rekomendujmy jej stosować. Niestety jest ona, ta pokusa, żeby relatywne estymacje porównywać, dostrzegamy ją niektórych firmach.

Kuba: Najbardziej wyrazisty przykład, jakie widziałem w jednej firmie, to jeden zespół, którego suma pracy z całego sprintu się sumowała do chyba 150 Story Pointów. Drugi zespół robił 20 Story Pointów. Pierwsza reakcja. Oooo, ten 150, to wyrobię nie wiadomo ile pracy. Tak naprawdę, w ogóle to nie był temat. Ten zespół ze 150 Story Pointami robił sobie swoją pracę. Tamten robił jakąś inną pracę. Oni po prostu mieli zupełnie inne skale. Natomiast z ostatnich czasach może, kilku lat, pewną popularność zdobywa w temacie stymulowania nurt braku estymowania. Niekoniecznie jest on jakoś ściśle zdefiniowany i wewnątrz tych głosów jest szereg różnych metod na brak estymowania. Postanowiliśmy z Jackiem, że w ramach tego nagrania po prostu podzielimy się pewnymi historiami z naszych w miarę najświeższych doświadczeń. Gdzie faktycznie, pomimo że może parę lat temu jeszcze byliśmy wielkimi fanami promowania estymowania relatywnego. To się okazuje, że wcale nie potrzebne jest to estymowanie do tego, żeby zespołu odnosiły sukces.

Jacek: Tak i tutaj, jeśli sięgnę pamięcią takie dobre półtora roku wstecz no to dosyć duża ilość zespołu, z którymi współpracuje to są zespoły nie software’owe. Nie wytwarzające produktu takiego IT. Żadnej aplikacji. Tylko po prostu wytwarzające różne produkty fizyczne. Bądź to są jakieś usługi, bądź produktem jest na przykład usprawnienia sposobu, w jaki funkcjonuje dział. No to takich zespołów bardzo ogólnie licząc myślę by było gdzieś tam pod osiem, mniej więcej. Tak bardzo luźno mówię z pamięci. Żaden z tych zespołów do planowania swojej pracy nie używał estymat. W sensie w Backlogu produktu nigdy nie pojawiły się żadne estymaty. Pomimo tego, że nie mieliśmy przypisanego oszacowania do poszczególnych elementów na liście rzeczy do zrobienia zespoły były w stanie planować pracę. No i co więcej, ta ich precyzja planowania była na naprawdę imponującym poziomie.

Kuba: Też mam podobne doświadczenia i od razu odpowiadając na pytanie, które się może rodzić. No to w takim razie skoro nie jest to w Story Pointach to jak? Część zespołów, o których myślę raczej szła z perspektywy, czy startowała z perspektywy celów sprintu. Czyli konkretny cel sprintu jest do osiągnięcia. Zgadzamy się jako zespół, że zrobimy wszystko, żeby go zrealizować. No i tak naprawdę w ramach toczących się prac było kilka opcji takiej głębi odwzorowania. To są twoje słowa Jacek, bo lubisz to powtarzać, że dany cel sprintu możemy osiągnąć w jakieś wersji maximum full wypas, jakaś wersja trochę biedniejsza, czy wersja absolutne minimum. Wszystko to, co jest absolutnie niezbędne. No i teraz zespół biorąc się za taką pracę przewiduje, że ta wersja będzie trochę bardziej rozbudowana. Jeśli się okazuje, że jednak wychodzą jakieś rzeczy nie tak korzystne, czy coś idzie nie tak jak trzeba, no to zespół po prostu w locie jakby osłabia swoje rozwiązanie. Obcina jego zakres. Nadal to jest akceptowalne. Nadal spełnia kryteria akceptacji. Nadal jest zgodne z DOD, czy z jakimiś standardami firmowymi. Jednak jest to rozwiązanie trochę prostsze. Idąc tym tropem w zasadzie cały zespół wraz z Product Ownerem, jeśli mówimy tutaj o Scrumie, jest w stanie ocenić kilka Sprintów w przód, jakie kolejne cele osiągną. Co się de facto zamienia w taką route mapę zorientowaną na cele. W tym Sprincie zrobimy tę próbę. W tym Sprincie kolejną próbę, a za trzy Sprinty będziemy gotowi do jakiegoś dużego wdrożenia lub czegoś tego typu.

Jacek: Gdybyście mieli, gdybyś miała apetyt na to, żeby takiego podejścia spróbować. Ja myślę, że tutaj kluczowe są dwa czynniki. Pierwsza rzecz to jest to co Kuba powiedziałeś związana z tym celem Sprintu. Czyli zwróć uwagę, że to jest takie bardzo mocno myślenie biznesowe raczej nastawione na osiągnięcie konkretnego rezultatu, a nie na to, żeby zrealizować jakieś konkretne zadania. Grając na konkretny cel jesteśmy w stanie trochę sobie manewrować tym jak bardzo fajny ten końcowy cel zostanie zrealizowany. Moim zdaniem to tak jeszcze takie zupełnie inne patrzenie przez zespół na pracę. Moim zdaniem jest to takie podejście bardziej biznesowe. Natomiast druga rzecz, która jest istotna w tym podejściu jest taka, że żeby zespół był w stanie planować jak to powiedziałeś to musi posiadać kontekst biznesowy, całkiem równomiernie rozłożony, albo umieć się świetnie dogadywać, żeby mieć to takie czucie, czy te rzeczy, które sobie planujemy tak jak mówisz. Czy na ten Sprint, na tę iterację, czy na kolejną? Czy to jest w ogóle wykonalne? W świecie, w którym zespoły nie mają kontekstu biznesowego i pracują w takim trybie mocno podwykonawczym. W sensie rozpisz mi to zadanie w Jirze. Jak już będzie to mi je daj, ja je zrobię. No to moim zdaniem takie podejście jest absolutnie kiepsko wykonalne, żeby nie powiedzieć nierealne, no bo nie chcę tutaj nikomu zamykać możliwości. W praktyce wierzę, że to jest bardzo ciężkie do zrobienia.

Kuba: W ramach tego odcinka nie będziemy już głębiej poszerzać tego wątku, ale jeśli interesuje Cię taki temat, który my czujemy jest trochę zaawansowany i trochę mimo wszystko jeszcze niszowy, jeśli chodzi o wykorzystanie podejścia zwinnego w takich realnych projektach biznesowych. Jeśli cię to interesuje to daj nam znać. Chętnie poszerzymy ten temat, bo jest on dla nas obu na pewno bardzo fascynujący i też taki bardzo świeży i na czasie. Natomiast łączy mi się to świetnie z myślą, którą chciałem przekazać na koniec. Wymieniliśmy podejścia do estymowania. Wymieniliśmy podejście klasyczne. Wymieniliśmy podejście relatywne. No i to najświeższe, ostatnie świeże związane z tym, żeby być może nie estymować tylko zabrać się po prostu za dostarczanie wartości biznesowej w krótkich iteracjach. Którego byśmy podejścia nie zastosowali, to najważniejsze to jest zadać sobie pytanie. Po co? Po co nam to estymowanie? Co ono nam daje? Co ono m daje jako specjaliście realizującemu jakiś projekt, czy inicjatywę, czy wykonujący prace nad jakimś produktem. Co ona nam daje jako cały zespół? Czy te estymaty do czegokolwiek mam się przydają? Niektóre estymaty niektórym zespołom przydają się do tego, żeby szybciej planować pracę, lepiej ją zrozumieć. Innym zespołem kompletnie to nic nie daje. No i wreszcie, czy te estymaty są potrzebne do czegoś szerzej w firmie? W niektórych firmach są potrzebne do planowania pracy kilku zespołów, synchronizowania jakichś czynności w zespole i poza zespołem. To są całkowicie uprawnione powody, żeby te estymaty powstawały i prognozy na ich bazie były budowane. W innych firmach wcale te warunki nie zachodzą, a niestety z powodu takiego mechanicznego podejścia do zwinnego podejścia do zastosowania na przykład Scruma. Te estymaty są robione, bo tak trzeba, bo tak było na szkoleniu, bo tak nam konsultant kazał i niekoniecznie cokolwiek nam przynoszą. W skrócie warto sobie zadać pytanie, sobie, pojedynczym zespołom, czy całej firmie. Co nam dają estymaty? Co z nich wynosimy? Czy zastosowanie tych naszych estymat spełnia tę potrzebę, jaką dana firma ma i jakie potrzebują nasze projekty?