Reestymować czy nie?

Od dłuższego czasu widzę kłótnie dwóch przeciwstawnych obozów – jedni uważają, że jest to zabronione, drudzy, że – wręcz przeciwnie – koniecznie trzeba reestymować wymagania (i są nawet gotowi pokazać na to wzmianki w Przewodniku po Scrumie). Między tymi skrajnościami odnajduje się część ekspertów, którzy są gotowi powiedzieć „to zależy”, żeby tylko nie narazić się żadnej ze stron – nie wyjaśniając przy tym, kiedy tak, a kiedy nie.

Zacznijmy od tego, co mam na myśli pisząc reestymowanie, czy przeszacowywanie wymagań. Chodzi tu o moment, kiedy kończy się iteracja (w Scrumie – Sprint), a część prac (Sprint Backlog Items) nie została zakończona (nie spełnia Definition of Done). I tu pojawia się odwieczne pytanie – zmieniać wartość szacowania tych prac, skoro zostały już w części zrealizowane, czy nie…?

Kiedyś byłem zdecydowanym zwolennikiem nieprzeszacowywania. Z biegiem lat i poprawą jakości narzędzi, moje spojrzenie na ten temat nie jest już tak czarno-białe.

Po co w ogóle szacujemy prace w Scrumie?

Bo przecież tak każe nam Przewodnik po Scrumie! Czyż nie?!

Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.

Co ciekawe ci, którzy tak głośno krzyczą o konieczności oszacowania, często zapominają o określaniu wartości tych elementów.

Faktycznie, Biblia Scruma mówi wprost, że zadania należy estymować (Manifest Agile i jego 12 zasad nie wspomina o tym ani słowem, więc jeżeli nie stosujesz Scruma, to jesteś bezpieczny i możesz nie estymować w ogóle ;-)). Jeff i Ken już nie raz mówili o tym, że w Scrum Guidzie nie ma zbędnych słów, więc po coś to szacowanie musi być.

Przez lata pracy z Zespołami Scrumowymi nauczyłem się, że szacowanie prac daje 4 główne wartości:

  • (najważniejsze) zmusza do dogłębnego zastanowienia się nad zadaniem – jeszcze przed jego rozpoczęciem, zachęca do dyskusji o nim i spojrzenia na nie z różnych perspektyw,
  • ułatwia Product Ownerowi podjęcie decyzji o tym, czy opłaca się dane wymaganie realizować (odnosząc do szacowanej wartości, którą może przynieść wykonanie tej pracy),
  • podczas Planowania Sprintu – ułatwia określenie jak wiele prac się w tym Sprincie zmieści lub przynajmniej jest sygnałem ostrzegawczym, gdy zbyt ochoczo przekraczamy naszą dotychczasową prędkość (velocity),
  • ułatwia nam szacowanie terminów kolejnych wydań.

Czy to oznacza, że bez szacowania prac nie da się działać? Nie! Widziałem wiele zespołów, które nie szacowały poszczególnych wymagań (a przynajmniej nie robiły tego w takiej formie, o jakiej tu mówimy), a osiągały świetne wyniki – znacznie powyżej przeciętnej. Ale o tym może przy innej okazji…

Na które wartości wpływa przeszacowywanie

Skoro już wiemy po co szacujemy, to zastanówmy się, na które z tych czterech wartości wpływa reestymacja. Gdy mówimy o elemencie Backlogu, który jest już wyszacowany, to zakładam, że pierwszą wartość już uzyskaliśmy – przygotowując to zadanie do Sprintu. Ponowna rozmowa o nim – gdy wiemy już więcej o zadaniu (a po rozpoczęciu prac nad nim na pewno wiele się dowiedzieliśmy) – wydaje się również być wartością dodaną.

Product Owner też pewnie będzie wolał wiedzieć, czy zadanie zostało rozpoczęte i w jak dużym stopniu zostało już zrealizowane. Niewzięcie do kolejnego Sprintu zadania, które jest już niemal ukończone w większości wypadków będzie marnotrawstwem. Z kolei realizowanie z uporem maniaka zadania, które ledwie ruszyliśmy, a już wiemy, że zajmie trzy razy więcej czasu (przy niezmiennej, ograniczonej wartości), to dopiero strzał w stopę, kolano, czy inną część ciała.

Planowanie Sprintu to ten moment, w którym większość zwolenników przeszacowywania dostrzega największą wartość. Wiele razy widziałem tę ekwilibrystykę, gdy zespoły broniły się przed przeszacowywaniem zadań, ale później na Planowaniu było „trzy w pamięci, dwa przesuń, osiem odejmij…”, co de facto było przeszacowywaniem, tylko nie w wymaganiu, a w głowach członków zespołu. Wiązało się to ze zdecydowanie większym wysiłkiem i często prowadziło do błędów w liczeniu, czego zespoły te zdawały się nie zauważać. Gdy zmienimy estymatę, większość narzędzi będzie nas wspierało w dalszym planowaniu.

Zmieniać? Nie zmieniać?

Kiedyś przekonany o wyższości niereestymowania nad reestymowaniem (i wyższości Bożego Narodzenia nad Wielkanocą), teraz jestem bliżej stwierdzenia „to zależy”. Jednak nie zamierzam zostawiać tego w niedopowiedzeniu. Poniżej wyjaśnię, kiedy – według mnie – można przeszacowywać zadania pomiędzy Sprintami, a kiedy nie należy tego robić.

Kiedy MOŻNA przeszacowywać:

  • jeżeli przeszacowujemy w górę (zadanie okazuje się większe niż początkowo sądziliśmy),
  • mamy narzędzia, które pozwalają nam zachować oryginalną wartość szacowania (np. do oceny velocity) i wspierają nas w tym,
  • wykorzystujemy szacowanie do oceny ile elementów Backlogu Produktu „zmieści się” w Sprincie – inaczej wartość z przeszacowywania jest bardzo ograniczona.

Kiedy NIE NALEŻY zmieniać estymaty (na niższą):

  • zadanie nie będzie realizowane w kolejnym Sprincie (jest „zrzucane do Backlogu”) – istnieje duża szansa, że gdy do niego wrócimy, trzeba będzie wszystko zacząć od początku (swoją drogą zespoły zbyt rzadko zastanawiają się na tym, czy rozpoczęte zadanie na pewno należy nadal realizować),
  • zadania nie udało się „dowieźć” już drugi Sprint,
  • wiemy, że zadania nie uda się dokończyć w kolejnym Sprincie (wtedy w ogóle nie powinniśmy go na ten Sprint brać, tylko powinniśmy je podzielić),
  • istnieje realna szansa, że w trakcie dalszych prac odkryjemy kolejne niespodzianki,
  • pracę w kolejnym Sprincie (z dużym prawdopodobieństwem) będą realizowały inne osoby niż dotychczas.

Jak reestymować

Zwracam szczególną uwagę, że napisałem „MOŻNA”, a nie „trzeba”, czy „powinno się”. Każdy powinien sam ocenić, które z rozwiązań przyniesie w danym zespole większe korzyści. Teraz już za to wiesz, co należy wziąć pod uwagę, podejmując tę decyzję.

Jeżeli jednak chcesz przeszacowywać zadania, to pamiętaj o tym, żeby wybierać raczej wartość większą, niż mniejszą. Jeżeli nie możemy się zgodzić co do tego, jak wiele pracy zostało, lepiej zostawmy oryginalną wartość.

Bądź stały w podjętej decyzji. Jeżeli dokonujesz zmiany, to niech się ona utrzyma chociaż przez kilka Sprintów. Jeżeli reestymujesz, to wszystkie zadania, a nie tylko wybrane.

I najważniejsze – na początku eksperymentu wprowadź mierniki do oceny, czy zmiana sposobu działania (z nieprzeszacowywania na przeszacowywanie lub odwrotnie) przyniosła faktyczne efekty i sprawdź po jakimś czasie, czy faktycznie tak się stało. Inaczej nie ma to nic wspólnego z empiryzmem, na bazie którego powstał Scrum.

Artykuł Reestymować czy nie? ukazał się oryginalnie na Linkedin.