Czy reestymować pracę?

Czym jest reestymowanie? Poznaj taktyki i podejścia, które są przydatne przy reestymowaniu. Nie zabraknie też przestróg związanych z ponownym oszacowaniem.

Jak podejść do reestymacji, czyli ponownego szacowania wyceny? Jakie są taktyki wykorzystywane w reestymacji oraz na co uważać?

O estymowaniu opowiadaliśmy w 19. odcinku naszego podcastu Porządny Agile, dlatego nie będziemy tutaj ponawiać tego wątku, tylko zachęcamy Cię do przesłuchania tego odcinka. Skupimy się stricte na reestymowaniu, temacie, który wyszedł podczas niedawnych warsztatów u jednego z klientów.

Czym jest reestymacja?

Reestymacja to po prostu aktualizacja estymaty, czyli aktualizacja oszacowania. Czasem jest to estymata mniejsza, kiedy odkrywamy, że tej pracy jest mniej, a może to być estymata większa, gdy odkrywamy, że pracy jest więcej. 

Szczególnym, ale i jednocześnie najczęstszym, przypadkiem reestymaty jest sytuacja, gdy mamy zadania nieskończone w jednym Sprincie, jednak prace nad nimi są już mocno zaawansowane. Wówczas pojawia się dylemat czy ponownie to reestymować. Do tego wątku powrócimy w dalszej części artykułu.

Innym powodem reestymacji może być sytuacja, w której wycena pierwotna po jakiejś późniejszej analizie lub rozpoczęciu pracy przez zespół okazuje się zła. Może też pojawić się jakaś nowa okoliczność czy wiedza, która powoduje, że dotychczasowa estymata przestaje być adekwatna do bieżącego stanu wiedzy.

Co ważne, mówimy tu o przypadkach, gdy konkretna praca została już wybrana do Backlogu Sprintu, do Sprintu lub konkretnej iteracji. Aktualizację estymat z Backlogu Productu realizuje się na wszelkiego rodzaju Refinementach.

Podejścia stosowane do reestymacji

Możemy wyróżnić kilka scenariuszy podejścia do reestymacji jakie możemy zastosować. Omówimy teraz 4 z nich.

1. Nigdy nie reestymujemy

Ta zasada mówi, że co by się nie działo, to nie zmieniamy pierwotnej estymaty. Nie ma dla nas znaczenia, czy praca została już rozpoczęta, ale nie jest skończona, czy są jakieś nowe informacje, czy po prostu wystąpiły nowe okoliczności. To twarda, a jednocześnie prosta i klarowna zasada, która bardzo upraszcza temat. Nie musimy otwierać nowych dyskusji, nie mamy nowych dylematów. Konsekwencją tego może być to, że Velocity będzie skakać. Zwłaszcza w zespołach, które nie kończą zadań w jednym Sprincie. Jeśli między Sprintami przyjdzie trochę więcej zadań, to w jednym z tych Sprintów bardzo wyraźnie spadnie velocity. Natomiast w kolejnym Sprincie, otrzymamy bardzo dużo Story Pointów z poprzedniego Sprintu. Tu z kolei skok Velocity może być bardzo wysoki.

Innym minusem tego podejścia jest to, że może ono utrudniać planowanie. W zespołach, które oceniają ilość pracy do wykonania w Sprincie poprzez dobór pewnej ilości Story Pointów, zespół może przestać wierzyć w te wyceny. 

2. Reestymujemy pracę do dokończenia

Tu nasza nowa estymata będzie określać tylko tę pracę, która pozostała nam do wykonania w kolejnym Sprincie, czy w kolejnej iteracji. Zaletą takiego podejścia jest to, że mamy prawdziwą informację ile pracy zostało do wykonania, a to pomaga zespołowi w planowaniu (jeśli bazują na swoim Velocity i Capacity). Jednocześnie skoki Velocity nie powinny mieć miejsca, a prędkość pracy zespołu się urealni. 

Minusem z kolei jest to, że zespół tak jakby “gubi” Story Pointy za poprzedni Sprint i to przepada. Ryzykiem z kolei może być to, że gdy podchodzimy ponownie do reestymacji tematu, który już dotknęliśmy, to bardzo uznaniowo oceniamy procent postępu prac i na tej bazie proporcjonalnie zmieniamy estymatę. To sprawia, że nasza estymata nie będzie precyzyjna, o ile w ogóle możemy mówić o precyzji w tym obszarze.

3. Reestymujemy wielkość elementu produktu

Podobne podejście do poprzedniego, gdzie reestymujemy wielkość elementu produktu. We wcześniejszej taktyce np. zespół pierwotnie ocenił coś na trzynastkę, po czym wykonał dużą część pracy, więc estymuje do piątki i wchodzi do następnego Sprintu z oceną wielkości pięć Story Pointów. Tu natomiast zespół bierze do pierwszego sprintu trzynastkę. Pracuję nad nią i przed rozpoczęciem następnego Sprintu lub nawet w trakcie Sprintu, jeśli zajdzie potrzeba reestymaty (np. okazuje się, że zadanie jest o wiele większe i zespół oceniłby je na dwudziestkę), to dokonuje się oceny zadania na nowo, wpisując nową wartość w tej pozycji, czy w tym polu estymata. I od tego momentu to zadanie staje się dwudziestką. 

Takie podejście powoduje, że ta wycena jest urealniona i wspiera prognozowanie oraz może służyć do wyciągania dalszych wniosków. 

Niestety może tu być trochę takie czarowanie statystyk, przez co nie do końca rekomendujemy to podejście. Zdarza się nam spotkać zespoły, które wykorzystują to do poprawienia Velocity, aby lepiej wypaść przed interesariuszami.

4. Reestymujemy po skończonej pracy

Najczęściej zespoły wybierają taki sposób działania, aby zorientować się już post factum, jak trafne są ich estymaty. Może to im bardzo pomóc w wyciąganiu wniosków na przyszłość i usprawnieniu całego procesu.  

Minusem tego podejścia jest to, że jest to czasochłonne, gdyż po każdym Sprincie trzeba przejść wszystko i dokonać ponownej estymaty. Ponadto jest to też bardzo uznaniowe i może pojawić się cała masa błędów poznawczych, utrudniając reestymacje.

Trzeba też wspomnieć, że taka ocena post factum nie pomaga nam w dobrej ocenie ryzyka i niepewności, zwłaszcza jeśli zadanie okazało się prostsze, co przecież wcale nie oznacza, że w przyszłości będzie tak samo.

Nim przejdziemy do porad, przypominamy, że nadal trwają zapisy na warsztaty Prawdziwe Przypadki Scrumowe. Temat wycen prognozowania pracy, czy monitorowania postępów jest jednym z dosyć popularnych problemów i pewnie będzie poruszany podczas warsztatów. Więcej informacji o zapisach znajdziesz na stronie 202procent.pl/przypadki-scrumowe. 

Reestymowanie pracy – porady natury ogólnej

1. Zastanów się po co w ogóle estymujesz – Pytanie o sens estymacji pojawia się zwłaszcza wtedy, gdy zespół zaczyna wchodzić w jakieś takie taktyki, które wydają się ryzykowne, podejrzane i otwierają jakąś niepotrzebną dyskusję. To wszystko może bardzo łatwo zahaczać o kult cargo, w którym wykonujemy reestymaty, działamy według jakiegoś konkretnego wzorca postępowania, który być może widzieliśmy w innym zespole, albo Scrum Master to przyniósł z poprzedniej firmy, a tak naprawdę może to nie mieć do końca sensu. Dlatego warto się zastanowić, do czego nam estymaty służą. Oczywiście mogą one służyć do wielu rzeczy jak np. do planowania, monitorowania prac, wycen finansowych, czy do oceny terminów. Jednak jeśli zajmują za dużo czasu, a nie przynoszą dodatkowych korzyści, to może warto z tego zrezygnować. 

2. Dąż do realizacji celów – Estymowanie to tak naprawdę drugorzędny proces, będący tylko taką pomocą dla zespołu. Ważniejsze jest to, czy regularnie dostarczamy wartość i czy regularnie odpowiadamy na potrzeby naszych klientów, użytkowników. Z perspektywy klienta to, czy estymujemy, czy nie, zwykle nie ma żadnego znaczenia.

3. Dobieraj taktyki reestymacji do celu estymowania – Przyczyny, dla których robimy estymaty, mogą czasami podsuwać konkretną taktykę reestymowania. Przykładowo, jeśli estymat nie stosujemy do planowania pracy w zespole, wtedy być może reestymowanie zadań, które przechodzą między Sprintami, nie ma żadnego znaczenia. Zmarnujemy tylko czas na to, żeby uzyskać Story Pointy, których później i tak nie użyjemy, bo planujemy pracę i  oceniamy jej ilość do wykonania zupełnie na inne sposoby. Warto sobie zadać pytanie, co miałyby te reestymaty nam dać i dopiero na tej bazie zastanawiać się, co z nimi zrobimy. No i dobierajmy takie taktyki, które zajmują jak najmniej czasu.
   
4. Stosuj konsekwentnie jedno podejście – Dobrą praktyką jest trzymanie się w ramach zespołu i podczas wielu Sprintów ustalonych zasad. To da nam miarodajne informacje i może stanowić dobry wsad do prognozowania. Jednak zachowajmy też pewną elastyczność i jeśli coś się nie sprawdza, dajmy sobie przestrzeń na usprawnienia.
   
5. Wyciągaj wnioski z potrzeby reestymowania – Warto też zadać sobie pytanie, z czego wynika to, że musimy mieć technikę na reestymowanie. Być może będzie lepiej poradzić sobie ze źródłem przyczyn, z których wynika to, że reestymowanie jest potrzebne, zamiast jak sobie z tym radzić. Być może warto podjąć decyzje o dekomponowaniu zadań na mniejsze, może planować mniejszą ilość pracy, a może należy robic lepszy proces Refinementu Backlogu Productu. Jest to temat do dyskusji, eksperymentowania i sprawdzania.

Jak to wygląda w Twoim zespole lub firmie? Robicie reestymaty? Jakie podejście stosujecie?

Zapraszamy Cię na webinar, którego temat wybrali słuchacze podcastu Porządny Agile. Będziemy na nim omawiać Dekompozycję elementów Backlogu produktu. Więcej informacji znajdziesz na stronie: porzadnyagile.pl/dekompozycja

Dodatkowe materiały

• Estymowanie

Transkrypcja podcastu „Czy reestymować pracę?”

Kuba: Podczas niedawnych warsztatów w pewnej organizacji, temat dyskusji pomiędzy Scrum Masterami, Product Ownerami i też managerami zespołów, zszedł na temat estymowania, a tak dokładnie reestymowania. Czyli przypadków, gdy praca wymaga ponownej wyceny. I temat zagłębiliśmy dosyć mocno w czasie tych warsztatów. Okazało się też, że w skali tak dużej organizacji jest bardzo dużo różnych podejść, bo tam kilkanaście zespołów było reprezentowanych przez różne role. No i pomyśleliśmy z Jackiem, że jest to temat też warty poruszenia w tym odcinku.

Jacek: O estymowaniu mówiliśmy już w różnych kontekstach w podcaście. Natomiast taki konkretny odcinek, gdzie rozmawialiśmy o możliwych podejściach do estymowania, znajdziesz pod adresem porzadnyagile.pl/19

Kuba: W tym odcinku nie będziemy dublować treści z tamtego odcinka. Nie będziemy też mówić o technikach uzyskiwania wycen. Natomiast, co będzie w odcinku, spis treści tego nagrania? Najpierw wyjaśnijmy i doprecyzujemy mocniej, co mamy na myśli, gdy mówimy o reestymowaniu. Później wymienimy te taktyki i możliwe podejścia do reestymowania. I na końcu kilka przestróg ogólnych, związanych z taktyką reestymowania, czy stosowaniem estymowania i reestymowania w konkretnym zespole.

 Jacek: Mówiąc w trakcie dzisiejszego odcinka reestymacji, mamy na myśli tak naprawdę aktualizację estymaty, czyli aktualizację oszacowania. Czyli mieliśmy ocenę wielkości konkretnego elementu, czy konkretnej pracy do wykonania, przygotowaną wcześniej, i z jakiegoś powodu przygotowujemy, ustalamy nową estymatę. Czasem jest to estymata mniejsza, kiedy odkrywamy, że tej pracy jest mniej, ale czasem może to być też estymata większa, kiedy odkrywamy, że pracy jest więcej. 

Kuba: Szczególnym przypadkiem takiej reestymaty jest, i chyba też najbardziej powszechna jest sytuacja, gdy są zadania nieskończone, w jednym na przykład Sprincie, no ale już poważnie rozpoczęte. No i jest dylemat, czy te zadania trzeba wyceniać, reestymować i to właśnie mam na myśli w tym odcinku i do tego wrócimy. Ale może być też sytuacja, w której wycena pierwotna po jakimś wyniku analizy, czy rozpoczęcia pracy zespół uznaje, że ta pierwotna wycena była zła. Może być też tak, że pojawia się jakaś nowa, ważna, istotna okoliczność, nowa wiedza, jakieś ważne, nowe doprecyzowanie, które powoduje, że zespół ma takie poczucie, że ta stara estymata, czy dotychczasowa estymata naprawdę przestaje być adekwatna.

Jacek: I jeszcze jedno doprecyzowanie, żebyśmy absolutnie byli na tej samej stronie. Mamy na myśli tylko te przypadki, gdy konkretna praca została już wybrana do Backlogu Sprintu, do Sprintu czy do konkretnej iteracji. Ponieważ aktualizację estymat z Backlogu Produktu traktujemy jako coś, co zwykle jest realizowane na wszelkiego rodzaju Refinementach.

Kuba: Zanim przejdziemy do konkretnych taktyk reestymacji, krótka autopromocja. Od kilku odcinków zapowiadamy nasz nowy produkt. Jeśli słuchasz lub słuchałeś lub słuchałaś poprzedniego odcinka, wiesz już, że to będzie webinar płatny. Słuchacze wybrali, głosowanie było bardzo zaciekłe. Łeb w łeb, kilka naszych propozycji szło przez cały ten czas. Pierwszym tematem będzie: Dekompozycja elementów Backlogu Produktu. Sprawdź porzadnyagile.pl/dekompozycja i kup dostęp do nagrania oraz materiałów dodatkowych w tym temacie. 

Jacek: Jeżeli chodzi natomiast o reestymowanie, to może być kilka scenariuszy, kiedy do reestymacji podchodzimy i przez te cztery scenariusze teraz przejdziemy.

Kuba: Pierwszy scenariusz i taka pierwsza zasada to zasada, że nigdy nie reestymujemy. Co by się nie działo, jaka by okoliczność się nie pojawiła, jakikolwiek z przypadków, które wymieniliśmy w tym wstępie definicyjnym, co mamy na myśli. Czyli nieważne, czy praca jest rozpoczęta, ale nie skończona, czy są jakieś nowe informacje, czy gdzieś tam zagłębiliśmy się i mamy jakieś dylematy, albo pokusy. Twarda zasada, prosta zasada, zostaje stara estymata. Czyli jak pierwotnie wyceniliśmy na trzynaście Story Pointów, albo na jakąś M-kę, jeśli stosujemy t-szirty, to po prostu ta estymata, zostaje i traktujemy to jako dokonaną wycenę. Nie wracamy do tego. Jest to zasada bardzo klarowna, bardzo prosta. Ona też jest jednocześnie przyspieszająca, bo nie musimy otwierać nowych dyskusji. Zwłaszcza jeśli proces dotarcia do wyceny jest w danym zespole dosyć pracochłonny, to zaoszczędzamy sobie drugiego czy trzeciego okrążenia tych dyskusji wyceniających. Po prostu przyjmujemy, że raz już wyceniliśmy i ta wycena z nami zostaje. Konsekwencją takiej zasady jest to, że może skakać velocity. W przypadku zespołów, które nie kończą zadań w jednym Sprincie, albo zdarza im się, że to nie kończenie się nasila. W takiej sytuacji, jeśli między Sprintami przejdzie trochę więcej zadań, to w jednym z tych Sprintów bardzo wyraźnie spadnie velocity. I to akurat jest może właściwy sposób zachowania tej miary. Natomiast w kolejnym Sprincie, jakby awansem, odziedziczymy bardzo dużo Story Pointów z poprzedniego Sprintu. Znowu tam, ten skok tego velocity może być bardzo wysoki. No i drugi minus, może to to, że takie podejście może utrudniać planowanie. Pod warunkiem że faktycznie używamy do tego samych estymat. Są zespoły, które oceniają ilość pracy do wykonania w Sprincie na planowaniu poprzez dobór pewnej ilości Story Pointów. I wtedy, jeśli do Sprintu wchodzi pewna porcja pracy częściowo wykonana, no to zespół przestaje trochę wierzyć w te faktyczne wyceny. 

Jacek: Drugie podejście stosowane do reestymacji to podejście, w którym reestymujemy prace do dokończenia. Czyli nasza nowa estymata będzie określała tylko tę pracę, która pozostała nam do wykonania najczęściej, w kolejnym Sprincie, czy w kolejnej iteracji. I z jednej strony jest to fajne, bo mamy prawdziwą informację, ile zostało nam pracy do wykonania. Co może pomóc zespołowi w planowaniu kolejnego Sprintu. Jeśli bazują oczywiście na swojej prędkości i na pojemności. Jednocześnie te skoki velocity, o których mówił Kuba, no to powinny nam zniknąć. Na takiej zasadzie, że prędkość naszego zespołu się urealni. Z minusów, które, choć często słyszę, to jest coś takiego, że zespół gubi story pointy czy jakiś inny sposób wyceny za poprzedni Sprint, no i to przepada. Jest oczywiście dyskusja, gdzie te Story Pointy lądują. Moim zdaniem w dev/null i tam jest ich miejsce, akurat w tym kontekście. Natomiast pewnym takim ryzykiem jest, to gdy podchodzimy ponownie do reestymacji tematu, który już dotknęliśmy. No, że ta nasza ocena jest taka dosyć uznaniowa. Oceniamy taki kawałek, procent postępu prac i na tej bazie proporcjonalnie zmieniamy estymatę. Próbujemy uchwycić. ile nam zostało. Natomiast jest tutaj szansa, że to po prostu nie będzie precyzyjna estymata, jeśli w ogóle możemy mówić o precyzji w tym temacie.

Kuba: Trzecia taktyka dosyć podobna do poprzedniej, więc spróbuję bardzo wyraźnie przez przykład pokazać różnicę. To reestymujemy wielkość elementu produktu. Ale w przeciwieństwie do tej poprzedniej, gdy powiedzmy zespół pierwotnie ocenił coś na 13-tkę, po czym wykonał dużą część pracy, więc estymuje do 5-tki, to byłaby ta taktyka przed chwilą wymieniona przez Jacka. Więc wchodzi do następnego Sprintu element z oszacowaniem, czy oceną wielkości pięć Story Pointów. W moim przypadku zespół bierze do pierwszego sprintu 13-tkę. Pracuję nad nią i przed rozpoczęciem następnego Sprintu, jeśli mamy do czynienia z tą potrzebą reestymaty, albo nawet i w trakcie Sprintu, gdy odkrywa, że na przykład zadanie okazuje się być o wiele większe, obiektywnie i z nową wiedzą ten zespół oceniłby jako 21-kę, to dokonuje oceny zadania na nowo, wpisując nową wartość w tej pozycji, czy w tym polu estymata. I od tego momentu to zadanie staje się 21-ką. Czyli, albo w środku Sprintu, albo na początku kolejnego Sprintu, ta ocena wielkości aktualizuje się, bo to jest generalizacja. Często to jest może też w dół, chociaż  pewnie najbardziej kłopotliwa jest sytuacja, gdy praca po prostu rośnie w rękach i wtedy ta ocena jest w górę. To powoduje, że ta wycena jest urealniona, być może przede wszystkim wspiera to proces prognozowania. Czy to oceny jakiejś zakresu wdrożenia, może jakieś daty wdrożenia, w zależności, od której strony w danym zespole jest to oceniane? Pomaga to też być może oceniać, tę pracę i wyciągać jakieś dalsze wnioski produktowe, na temat wielkości, złożoności, kosztochłonności danych funkcji w produkcie. Może się też okazać, że zespół stosuje to podejście, troszkę maskując sytuację, w której wzięty element, czy podjęty element do pracy naprawdę realnie nie był do końca gotowy do rozpoczęcia. Może była presja czasu, może zespół nie jest wystarczająco asertywny? Może interesariusze się niecierpliwi? No i zadanie zostało podjęte, ale tak naprawdę ocenione zostało niedoskonale. I to nie na zasadzie tego, że każda estymata jest niedokładna, tylko po prostu tutaj na przykład nie było kompletu informacji. Ale może się też zdarzyć tak, że zwłaszcza przykład w bardziej rozbudowanych produktach, w bardziej rozbudowanych systemach, też może z jakąś większą historią, po prostu pewne prace zawsze zaskoczą. Na zasadzie, zima zaskakuje drogowców, święto zaskakuje marketing. I nagle się okazuje, że jednak jest coś większego, więcej pracy do wykonania, jakieś dodatkowe czynności, które nie były przewidywane. Największe ryzyko z tą taktyką, szczerze mówiąc, nie do końca ją sam osobiście rekomenduję, to to, że to może być dosyć prosta furtka do czarowania statystyk. Czyli od czasu do czasu, oczywiście to jest większa historia, dlaczego tak się dzieje, ale od czasu do czasu spotykam zespoły, które wykorzystują taką okazję do reestymat, żeby sobie może trochę podpompować velocity. Może trochę sobie dobrze zrobić, na zasadzie dobrego humoru. A może niestety, ale zadowolić jakieś otoczenie. Być może lepiej wypaść w jakiś raportach, albo może mniej narażać na gniew klienta w zależności od sytuacji. W każdym razie, tutaj najwyższe ryzyko, akurat w tej taktyce spośród tych wymienionych widzę właśnie w tej kwestii odrobiny uznaniowości w ocenie tych miar, które no i tak nie są aż takie doskonałe i tak precyzyjne. I tu my możemy sobie może jako zespół jeszcze bardziej pogarszać. 

Jacek: Ostatnia sytuacja, kiedy reestymujemy, może wystąpić, gdy dokonujemy tego już po skończonej pracy. Najczęściej zespoły wybierają taki sposób działania, by zorientować się już post factum, na ile trafnie wycenialiśmy, po to, żeby na przyszłość wiedzieć, jak trafne są nasze estymaty. Sam pamiętam, że wykorzystałem takie podejście w jednym z zespołów, w którym pracowałem jako Scrum Master i byliśmy w stanie dosyć jasno powiedzieć, z jakim prawdopodobieństwem jedynka będzie jedynką, dwójka dwójką itd. Tak więc przykładowo wiedzieliśmy, że jakieś estymaty powyżej 13-tu, są po prostu, szansa na to jest, powiedzmy, już nie pamiętam dokładnych liczb, ale powiedzmy 60 procent. Co oznaczało, że jest spora szansa, że to po prostu będzie większe. Bo to zwykle niestety, ale idzie w tę stronę. Tak więc może to być źródło bardzo fajnych danych do zespołu. Być może wpłynie to na przemyślenia zespołu w tym temacie, jak podchodzić do estymowania i jak można byłoby usprawnić proces. Natomiast na pewno jest to z minusów, podejście czasochłonne, no bo tak naprawdę po każdym Sprincie musimy przejść po całej pracy i dokonać ponownej estymaty, czyli właściwie reestymaty. No i znów ten problem, o którym już mówiliśmy, czyli pewna taka uznaniowość. Na zasadzie no, już teraz to robiliśmy. No i cała masa, myślę tutaj błędów poznawczych, może nam ten temat utrudnić. Takim szczególnym przypadkiem jest to, że ta ocena post factum nie pomaga nam w dobrej ocenie ryzyka i niepewności. Coś, co zwykle ma jakieś przełożenie na estymatę relatywną. W szczególności, gdy zadanie okazało się prostsze. Bo to nie oznacza, że wszystkie inne w przyszłości również będą takie łatwe. Tak nam po prostu akurat w tym konkretnym przypadku wyszło.

Kuba: To może w ramach tych taktyk, które po kolei wymienialiśmy i tak dość szczegółowo opisywaliśmy, podsumujemy jeszcze te konkretne cztery praktyki, które ustaliliśmy. Pierwsza z nich to podejście, w którym nigdy nie reestymujemy. Czyli powiedzmy, była trzynastka, zostaje w następnym trzynastka, niezależnie od tego, jakie są nowe okoliczności, albo wykonana praca. Drugie podejście reestymujemy pracę. Do dokończenia była trzynastka. Oceniamy, że jest jeszcze osiem Story Pointów do wykonania. Od teraz jest to 8 Story Pointów. Trzynastka znika. Trzecie podejście. Reestymujemy wielkość elementu produktu. Była trzynastka. Okazuje się, że jest większa od teraz. To jest dwudziestka jedynka i wchodzi do nowego Sprintu jako dwudziestka jedynka. No i podejście takie może najrzadsze. Reestymujemy pracę, ale dopiero po zakończonej pracy. Być może w ramach jakiejś refleksji. Była trzynastka. Post factum, jak już skończyliśmy, jak już podsumowaliśmy, jak to jest faktycznie całkowicie skończone. To jako zespół ustalamy, teraz jak patrzymy na siebie za plecy, to wygląda na to, że to jednak była dwudziestka jedynka. Zastanówmy się co z tym zrobić w przyszłości. 

Kuba: Zanim przejdziemy do porad natury ogólnej, przypominam też, że nadal trwają zapisy na warsztaty Prawdziwe Przypadki Scrumowe. Tak się akurat składa, że temat wycen prognozowania pracy, monitorowania postępów, też jest jednym z dosyć popularnych problemów. Zawarty jest w kilku case’ach związanych właśnie z projektami, które mają kłopoty. I ten temat też będzie poruszany, albo będzie składową wybranych przypadków. Zapisy niezmiennie na 202procent.pl/przypadki-scrumowe. 

Jacek: Mamy dla Ciebie też kilka porad natury ogólne,j jeśli chodzi o reestymowanie pracy.

Kuba: Pierwsza porada natury ogólnej, to zastanów się, po co w ogóle estymujesz. To bardzo ważne zastrzeżenie i tutaj na razie powstrzymaliśmy od tego stwierdzenia we wcześniejszych momentach. Ale to jest pytanie, które się natychmiast budzi, zwłaszcza gdy zespół zaczyna wchodzić w jakieś takie taktyki, które wydają się ryzykowne, podejrzane, otwierają jakąś niepotrzebną, dodatkową dyskusję. To wszystko może bardzo łatwo zahaczać o kult cargo, w którym wykonujemy reestymaty, działamy według jakiejś konkretnej techniki, według konkretnego jakiegoś wzorca postępowania, który być może widzieliśmy w innym zespole, albo Scrum Master nam to przyniósł z poprzedniej firmy. Ale tak naprawdę to może nie mieć do końca sensu. Więc tutaj warto się zastanowić, do czego nam estymaty służą. A one mogą służyć do naprawdę wielu, wielu zastosowań. Bo to może być i do planowania, i do decyzji Product Ownerskiej, i do monitorowania prac, i do wycen, i do takich finansowych, i do oceny terminów. W zależności od tego, jaka dokładnie jest kombinacja tych zjawisk u Ciebie w zespole, może się okazać, że tutaj zajmie Ci to sporo czasu, a niekoniecznie da dodatkowe korzyści. Czyli zastosujesz jakąś taktykę, która może była potrzebna i sprawdza się w jednych realiach, ale w tych konkretnych zupełnie nie będzie bez sensu. 

Jacek: Druga porada, dąż do realizacji celów. Sporą część, właściwie całą odcinka poświęciliśmy na rozmowę o estymowaniu. Natomiast patrząc na to z innej perspektywy, dla wielu osób to może być po prostu pewne marnotrawstwo. Na zasadzie, że to jest tylko estymata. A przecież spędzamy masę czasu, żeby estymować, reestymować, wybierać jedną z tych strategii, którą zaproponowaliśmy, albo nawet  je łączyć. I taka myśl, którą chcemy przekazać, jest taka, że tak naprawdę istotne jest to, czy regularnie dostarczamy wartość, czy regularnie odpowiadamy na potrzeby naszych klientów, użytkowników. Estymowanie, tak naprawdę to jest, można powiedzieć jakiś drugorzędny proces, będący tylko taką pomocą dla nas, dla zespołu. Czasem organizacja tego wymaga, trochę to dotyka tego, co Kuba mówiłeś przed chwilą. Natomiast z perspektywy klienta to, czy estymujemy, czy nie, tak naprawdę nie ma najczęściej żadnego znaczenia.

Kuba: Trzecia porada, to dobieraj taktyki reestymacji, do celu estymowania. To łączy się z tym, co mówiłem chwilę temu, czyli te przyczyny, dla których robimy estymaty, mogą czasami podsuwać tą, a nie inną taktykę reestymowania. I chociażby przez przykład, jeśli estymat nie stosujemy do planowania pracy w zespole, czyli np. planowanie pracy w danym Sprincie odbywa się, albo na zasadzie budowania jakiegoś bardziej szczegółowego planu, albo zupełnie odwrotnie, na totalne wyczucie. Na takim lajcie. Ty Jacek chyba na to mówisz, że tak jak to czujemy, jak to mamy w brzuchu. Podejścia mogą być bardzo różne, ale nie wszystkie wymagają bardzo ścisłych ocen wielkości zadania. I wtedy być może reestymowanie zadań, które przechodzą między Sprintami, nie ma żadnego znaczenia. Jakby zmarnujemy czas na to, żeby uzyskać Story Pointy, których później i tak nie użyjemy, bo planujemy pracę, oceniamy ilość pracy do wykonania zupełnie na inne sposoby. Więc tutaj nie ma jedynej słusznej odpowiedzi. Różne zespoły, różne firmy, być może nawet w obrębie jednej firmy, bardzo różne jakieś produkty, czy różne usługi mogą mieć po prostu zupełnie inne zastosowania, i to może być ok. Warto się zastanowić. Warto sobie zadać pytanie, co nam miałyby te reestymaty dać i dopiero na tej bazie zastanawiać się, co z nimi zrobimy, bo już trzeci raz powtórzymy. Może być tak, że całe to estymowanie to jest marnotrawstwo i po prostu je minimalizujmy. Więc siłą rzeczy też dobierajmy takie taktyki, które zajmują jak najmniej czasu. 

Jacek: Czwarta porada brzmi, stosuj konsekwentnie jedno podejście. W ramach swojego zespołu warto trzymać się pewnych ustalonych zasad. Myślę, że na co najmniej kilka Sprintów po to, żeby mieć miarodajne informacje. Jeżeli będziemy nie trzymać się ustalonych zasad, albo ze zbyt dużą częstotliwością zmieniać podejście do tego, jak podchodzimy do reestymowania, to wszystkie liczby, które z tego dostaniemy, a w konsekwencji też jakiś wsad do prognozowania, jeśli chodzi o planowania, no po prostu może być bardzo niewiarygodny, co może myślę doprowadzić do takiego poczucia, tyle czasu o tym rozmawiamy, tyle czasu nad tym spędzamy, a tak naprawdę w sumie nic nam z tego nie wynika. Tak więc pewna konsekwencja po to, żeby pozwolić trendom się wyłonić, będzie tutaj na pewno konieczna. I tak jak, nazwijmy to, lokalna konsekwencja jest ważna, istotna, żeby pozwolić danym pokazać nam jakiś sensowny obraz. No to, co do zasady myślę, że słuchacz, który jest z nami dłużej, wie, że rekomendujemy mimo wszystko podejście, żeby usprawniać, żeby szukać sposobów na lepsze wykorzystywanie estymat, jeżeli już się na nie zgodziliśmy. Tak więc w pewnym sensie trzeba tutaj łączyć ogień i wodę. Z jednej strony trzymać pewną konsekwencję, żeby pomiar miał sens, z drugiej strony mimo wszystko znaleźć też czas i przestrzeń na usprawnienia.

Kuba: I ostatnia porada wyciągaj wnioski z potrzeby reestymowania. Tutaj wraca ta myśl, że to reestymowanie może wynikać z tego, że coś zostało niedopilnowane. Może zabrakło asertywności, może mamy niewystarczająco dobrze zrealizowane Definition of Ready. Więc tutaj, gdy przychodzi czas na dyskusję w zespole o reestymowaniu, zwłaszcza jako Scrum Master, ale też trochę jako Product Owner, z tej perspektywy, nie tylko rozmowy o tym, jak sobie radzić z reestymowaniem, ale też od razu wejść w rozmowę. A tak w ogóle to z czego to wynika, że ten temat nam wraca? Z czego to wynika, że w ogóle musimy mieć taktykę na reestymowanie. I być może lepiej byłoby sobie poradzić ze źródłowymi przyczynami, z których wynika to, że to reestymowanie jest potrzebne. Niekoniecznie spędzać np. pół czy całą Retrospektywę, a może nawet kilka, na dyskusję o tym, jak sobie z tym radzić. Więc być może jest tutaj do zrobienia temat typu, czy decyzja o tym, żeby dekomponować zadania na mniejsze. Co tu znowu kłania się nasz webinar. Może planowanie mniejszej ilości pracy, żeby ta praca się nie przelewała, żeby gdzieś tam nie przelewała capacity zespołu. Może więcej, albo lepszy proces Refinementu Backlogu Produktu i rozwiązań może być kilka. Oczywiście to jest temat do dyskusji i do rozpoczęcia pewnego eksperymentu, śledzenia pewnego trendu, żeby lepiej zrozumieć, co się dzieje, ale też, żeby nie unikać tej rozmowy. Bo może się okazać, że po powierzchni wybierzemy sobie sprawnie sposób na reestymowanie i on będzie nam pasował i nie będzie nas tak bardzo bolał. A tak naprawdę powinno tematem dyskusji być to, dlaczego w ogóle musimy reestymować?

Jacek: Podsumowując. Jakie mamy porady w temacie reestymowania? Zastanów się, po co w ogóle estymujesz. Dąż do realizacji celów. 

Kuba: Taktyki reestymacji dobieraj do celu estymowania. Stosuj konsekwentnie jedno podejście i wyciągaj wnioski z potrzeby reestymowania.

Jacek: Notatki do tego odcinka. Artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/95 

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek, 

Kuba: Dzięki Kuba.