Po opublikowaniu artykułu o wycenach elementów Backlogu Produktu zapytany zostałem o opinię na temat zmiany oszacowań już po rozpoczęciu developmentu albo wręcz po jego zakończeniu. Czy wolno to robić? Czy ma to sens?

Zmiany oszacowań a Scrum Guide

W Scrumie nie istnieje żaden formalny wymóg szacowania czegokolwiek, nie są też w nim opisane żadne zasady, wedle których wyceny miałyby być sporządzane. Pozostaje to całkowicie w gestii Zespołu Scrum. Jeśli zatem uzna on, że estymaty trzeba zmienić, może tego dokonać w dowolnym momencie.

Warto przy okazji przypomnieć, że żadne oszacowania nie stanowią kontraktu lub zobowiązania Zespołu Scrum albo Developerów w nim do czegokolwiek względem interesariuszy, lub kogokolwiek innego. Inaczej mówiąc, celem Zespołu nie jest działanie zgodne z oszacowaniami, ale rozwój produktu w sposób, którzy przynosi korzyści interesariuszom. Wszelkie wyceny i procesy z nimi związane mają w tym pomagać, a nie stać się celem samym w sobie.

Mówiąc jeszcze bardziej wprost: Zespół ma zrobić to, co jest niezbędne, by osiągnąć ustanowiony Cel Sprintu i wytworzyć wartościowy produkt, niezależnie od tego, czy będzie się to działo zgodnie ze wcześniejszymi oszacowaniami i tworzonymi na ich podstawie prognozami. Jasne, duża rozbieżność między prognozami a przebiegiem prac zmusza do poszukania odpowiedzi o przyczyny takiego stanu spraw, ale nieporozumieniem byłoby skupienie Zespołu przede wszystkim na pracy zgodnie z estymatami za wszelką cenę.

Backlog Sprintu

Rozważania o zmianie oszacowań w trakcie developmentu lub już po jego zakończeniu związane musi być z Backlogiem Sprintu. Dlaczego? Wszystkie elementy Backlogu Produktu, jakie podjęte zostały do realizacji w Sprincie, nie znajdują się już bowiem w Backlogu Produktu, ale stanowią część Backlogu Sprintu.

Zgodnie z definicją zawartą w Scrum Guide, na artefakt ten składają się z trzy komponenty:

  1. Cel Sprintu,
  2. prognoza zmian w produkcie (na nią składają się elementy Backlogu Produktu),
  3. plan osiągnięcia Celu Sprintu i zarazem realizacji prognozy.

Z którymi komponentami Backlogu Sprintu wiążą się jakiekolwiek oszacowania?

Celu Sprintu

Celu Sprintu stanowi wyjaśnienie powodu, dla którego Sprint w ogóle się odbywa. Inaczej mówiąc, to odpowiedź na pytanie, co interesariusze będą mieć z tego, że Zespół Scrum zrealizuje Sprint.

Cel ten stanowi więc swoiste oszacowanie wartości, jaką Zespół Scrum spodziewa się wykreować dzięki pracy w iteracji.

Ponieważ Celu Sprintu w trakcie iteracji zmienić nie można, w dalszych rozważaniach go pominę.

Prognoza zmian w produkcie

Elementy Backlogu Produktu nie muszą być jakkolwiek oszacowane, ale prawie zawsze Developerzy sporządzają dla Product Ownera jakąś ich wycenę, by podpowiedzieć, jak kosztowna będzie realizacja zmian w produkcie. To pozwala rezygnować z prac, które są zbyt kosztowne w stosunku do spodziewanej korzyści. Dzięki takim oszacowaniom da się też z wyprzedzeniem zidentyfikować zmiany, których nie da się zrealizować w czasie jednego Sprintu, i które muszą w związku z tym zostać realizowane inkrementalnie.

Wartość wspomnianych wycen kończy się na Planowaniu Sprintu. W jego trakcie dyskusja toczy się nie wokół estymat ustalonych w przeszłości, ale konkretnych rozwiązań, które muszą zostać zbudowane z wykorzystaniem dostępnych aktualnie środków, ludzi i możliwości. Chodzi bowiem o stworzenie realistycznego planu działania, który pozwoli osiągnąć ustalony Cel Sprintu. Konieczne jest oszacowanie czasochłonności poszczególnych elementów tego planu, identyfikacja zależności oraz stworzenie prognozy dostępności narzędzi, materiałów i ludzi z niezbędnymi kompetencjami. Podkreślam, że chodzi o szacowanie i prognozowanie, które odbywa się w trakcie Planowania Sprintu, a nie o proste sięgnięcie po wcześniejsze wyceny, jeśli takowe są dostępne.

Oryginalna estymata jakiegoś elementu Backlogu Produktu, jeśli w ogóle istniała, może od biedy przydać się przy podejmowaniu decyzji o jego realizacji w bieżącym Sprincie, ale nie ma żadnego znaczenia dla developmentu. Jego przebieg nie jest przecież wynikiem oszacowań poczynionych w przeszłości, ale tego, co dzieje się w iteracji na bieżąco.

Wydaje się, że marnowanie czasu na zmianę estymat po rozpoczęciu developmentu powstrzyma Zespoły od robienia tego. Jest jednak kilka typowych powodów, dla których mimo wszystko decydują się one na to – większość z nich mało sensownych.

Powód 1: zapewnienie przejrzystości

Jeśli wyceny są zmieniane, aby skorygować błędne oszacowanie na podstawie empirycznej wiedzy pozyskanej przez Developerów już w trakcie developmentu, to czysta strata czasu. Nie wpłynie to w żaden sposób na ilość pracy, jaką Developerzy będą musieli wykonać, a może zabrać cenny czas, który zamiast na development poświęcą na szacowanie.

Empiryzm wymaga przejrzystości, ale należy ją rozumieć jako dostęp do rzeczywistych danych, które pozwalają podejmować decyzje na podstawie faktów. Tymczasem:

  • żadna wycena nie jest faktem i stanowi jedynie próbę przewidywania przyszłości,
  • decyzje podejmowane w trakcie developmentu nie wynikają z takiego czy innego oszacowania realizowanej zmiany w produkcie,
  • zmiana wyceny już po wykonaniu pracy nie pozwoli wykonać tej pracy lepiej i nie wpłynie na jej rezultaty.

Nieadekwatna estymata nijak przejrzystości nie obniża (a już na pewno nie na etapie developmentu). Zresztą, gdyby wyceny stanowiły narzędzie podnoszenia przejrzystości, byłyby w Scrumie wymagane, a nie są…

Powód 2: precyzyjne monitorowanie postępu prac w Sprincie

Wiele Zespołów posługuje się w jakiejś formie wycenami elementów Backlogu Produktu do sprawdzenia, czy przebieg developmentu jest efektywny, czy też idzie zbyt wolno. Używane do tego są różne narzędzia, z wykresem spalania Sprintu (ang. Sprint burndown chart) na czele. Jeśli estymata jest zaniżona lub zawyżona w stosunku do faktycznej ilości pracy, jaką muszą wykonać Developerzy, jest ona pospiesznie aktualizowana, żeby pokazać „faktyczny postęp prac”. Cóż, to bzdura.

Z informacji, że „z estymowanych ośmiu story pointów udało się już zrealizować cztery, a kolejne cztery pozostały do wykonania”, nie wynika dokładnie nic. Nawet to, że prace są na półmetku. Jest to bowiem oszacowanie (czyli zgadywanie) odnoszące się do innej wyceny (będącej efektem wcześniejszego zgadywania). Jedyną faktyczną informacją, którą można z tego wyciągnąć, jest to, że prace jeszcze nie zostały ukończone, a to wiadomo i bez zmian oszacowań.

Ten sposób mierzenia postępu prac jest w istocie generowaniem złudzeń, że następuje jakiś postęp prac – jeśli Zespół faktycznie chce ten postęp mierzyć, powinien poszukać lepszych narzędzi. Dobrym ich zasobnikiem jest Kanban i związane z nim praktyki wizualizacji i monitorowania przepływu.

Powód 3: podział elementu Backlogu Produktu w trakcie realizacji

Jeśli Developerzy dojdą do przekonania, że nie uda się zrealizować całości prognozowanych zmian w produkcie, mogą wraz z Product Ownerem poszukać sposobu na podział niektórych elementów Backlogu Produktu już w trakcie developmentu.

To pozwoli oddzielić rzeczy niezbędne, które muszą zostać zrobione, od tego, co można zrobić później. Wyznacznikiem jest tu oczywiście Cel Sprintu: Zespół szuka sposobu, by odchudzić zakres prac tak, by Cel ten osiągnąć w sytuacji, gdy development okazał się trudniejszy, niż wskazywały wcześniejsze prognozy.

Dyskusja o dekompozycji może być trudna, a jej częścią może być szacowanie wielkości lub wartości części składowych dzielonego na kawałki elementu Backlogu Produktu. I wtedy jak najbardziej takie szacowanie może mieć sens, ponieważ odbywa się po to, by zasilić proces decyzyjny niezbędnymi informacjami, a nie tylko dla uaktualnienia wcześniejszych wycen.

Powód 4: ustalenie ostatecznej wartości oszacowań

Z definicji wszystkie estymaty są błędne i jeśli uda się idealnie utrafić z ich wartością, jest to zwykle przypadek. Niektóre Zespoły uznają więc za niezbędne, by na koniec, po zakończeniu realizacji konkretnego elementu Backlogu Produktu, raz jeszcze go oszacować – tym razem „poprawnie”. Dzieje się to z kilku różnych przyczyn, które czasami mogą mieć sens, a czasami powinny zapalać lampki alarmowe.

Powód 4.1: uzyskać wzorcowe elementy Backlogu Produktu

Jeśli celem jest chęć uzyskania wzorcowych elementów Backlogu Produktu, które posłużą jako punkty odniesienia w trakcie szacowania kolejnych elementów, to być może ma to jakiś sens. Moim zdaniem ograniczony o tyle, że bardzo rzadko prace nad złożonym produktem są na tyle powtarzalne, by takie porównywanie było wartościowe.

Mam też zawsze obawy, że Developerzy skupią się w przyszłości na sporze o różnice między wzorcem a nowym elementem Backlogu Produktu, który aktualnie szacują, zamiast dążyć do dobrego zrozumienia tego elementu.

Powód 4.2: podniesienie precyzji szacowania

Niewykluczone zresztą, że te ostateczne wartości oszacowań mają za zadanie pomóc w podniesieniu precyzji przyszłych oszacowań. Jest to cel z definicji utopijny, ponieważ precyzyjne estymaty to oksymoron. Zwykle jest tak, że ten pozorny wzrost precyzji wiąże się z wykładniczym wzrostem czasu i wysiłku idącego na analizy i dyskusje o wycenach. Dlaczego pozorny? Ponieważ przeszłości nie da się przewidzieć i od pewnego momentu dalsze inwestowanie w próbę zrobienia tego lepiej nie daje już nic poza złudzeniami.

Powód 4.3: precyzja wyliczenia velocity i sporządzanych prognoz

Innym celem może być chęć wyliczenia prędkości (ang. velocity) na podstawie najbardziej aktualnych danych. Pomijając już niską użyteczność tej miary, takie ostateczne wartości oszacowań wcale nie wpłyną na wzrost sprawdzalności prognoz w kolejnych Sprintach. Dlaczego?

Cóż, na precyzję takiej prognozy składa się nie tylko dokładność wyliczenia velocity, ale również błąd oszacowań elementów znajdujących się aktualnie w Backlogu Produktu.

Żeby faktycznie miało to jakiś umiarkowany sens, należałoby po każdym Sprincie nie tylko ustalać ostateczne oszacowania wszystkich zrealizowanych elementów Backlogu Produktu, ale jeszcze dokonać weryfikacji (i ewentualnej zmiany) oszacowań w Backlogu Produktu (uwzględniając najnowszy stan wiedzy). Wtedy faktycznie precyzyjniej wyliczone velocity nakładane byłoby na najaktualniejsze możliwe oszacowania. Tyle że zabrałoby to od groma czasu, dając niewiele w zamian.

Istnieją prostsze sposoby, by udoskonalić sposób prognozowania. W szczególności można nawet nic nie szacować, ale za pomocą symulacji Monte Carlo, dysponując jedynie wiedzą o przepustowości (ang. throughput, określany jako liczba ukończonych elementów Backlogu Produktu w jednostce czasu), da się tworzyć prognozy wykorzystujące probabilistykę.

Powód 4.4: monitorowanie i doskonalenie procesu szacowania

Niektóre Zespoły szacują każdy element Backlogu Produktu po zakończeniu pracy nad nim po to, by ocenić, jak bardzo nietrafiona była pierwotna estymata. Do czego można użyć takich danych? Choćby do próby określenia czy proces szacowania degraduje się, jest w miarę powtarzalny, czy też zaczyna działać lepiej. Albo do oceny poziomu niepewności (skali błędu) dla sporządzanych oszacowań.

To może mieć sens, ale będzie zabierać sporo czasu, niekoniecznie dając korzyści przeważające nad kosztami. Powody, dla których oszacowania czasami są bardziej trafione, innym razem kompletnie błędne, mogą być przeróżne i zmieniać się w funkcji czasu.

Takie statystyki mają spory potencjał wygenerowania w Zespole chęci uzyskania precyzyjnych oszacowań, o których pisałem wcześniej. Mają też czasami i inny efekt: Zespoły zaczynają być coraz bardziej zachowawcze, gdy statystyki wykazują, że precyzja oszacowań zmalała. Boją się, że praca wybuchnie im w rękach. Po czym mając więcej czasu do dyspozycji, w myśl prawa Parkinsona, zaczynają pracować wolniej, niżby mogły, przez co robota i tak kończona jest na styk. Wiedzie to do fałszywego wniosku, że faktycznie estymaty były nietrafione, więc ta zachowawczość była „rozsądną decyzją”. I niestety wtedy zachowawczość staje się normą.

Powód 5: wykazanie się produktywnością

Najgorszym możliwym powodem, dla którego Zespoły zaczynają zmieniać oszacowania elementów Backlogu Produktu już w trakcie realizacji albo po jej zakończeniu, jest chęć udowodnienia, że więcej zrobić się nie dało. Czyli wykazania za pomocą wycen (i pewnie wyliczonego na ich bazie velocity), że w Sprincie „dowieziono” tyle, co zwykle albo i więcej.

Jest to cel z gruntu chybiony i dążenie do jego osiągnięcia jest szkodliwe, ale niekoniecznie należy za to ganić Zespół lub Developerów w nim. Być może oczekuje się od nich gwarancji zrealizowania prognozy (co jest absurdem, bo prognoza nie jest kontraktem, tylko hipotezą, że coś da się zrobić i przyniesie to wartość) i muszą gęsto tłumaczyć się za każdym razem, gdy się to nie uda. A niewykluczone, że dla organizacji miarą efektywności działania jest właśnie to, że dużo „dowieziono”, nie zaś to, jaką przyniosło to realną korzyść komukolwiek.

Plan osiągnięcia Celu Sprintu i realizacji prognozy

Wróćmy do Backlogu Sprintu i jego trzeciego komponentu składowego, z którym również mogą być związane oszacowania. Plan, o którym mowa, może mieć różną formę, zależną od sposobu pracy Developerów – Scrum nie narzuca tutaj żadnych konkretnych praktyk.

Wiele Zespołów dokonuje dekompozycji elementów Backlogu Produktu w trakcie Planowania Sprintu na mniejsze elementy, czyli tzw. elementy Backlogu Sprintu (ang. Sprint Backlog item, w skrócie SBI). Inne Zespoły tworzą listy kontrolne (ang. checklist) rzeczy do zrobienia. Jeszcze inne definiują zadania (ang. task) opisujące czynności, jakie trzeba będzie wykonać.

Zarówno wspomniane SBI, jak i listy kontrolne lub zadania, mogą być wyszacowane w sposób, jaki Developerzy (do których w Scrumie należy Backlog Sprintu) uznają za właściwy. Będą to najczęściej oszacowania czasochłonności konkretnych działań wykonywanych często w ściśle określonej kolejności.

Jeśli Zespół realizuje usprawnienia (w myśl ustaleń poczynionych w trakcie Retrospekcji Sprintu poprzedniego), one również mogą być na różne sposoby oszacowane przez Developerów w trakcie Planowania Sprintu.

Wszystkie takie wyceny są związane z bieżącym planem działania Developerów w Sprincie. Ten plan nie jest statyczny, czyli w praktyce zmienić się musi za każdym razem, gdy Developerzy odkryją coś, o czym wcześniej nie wiedzieli, a co ma wpływ na sposób realizacji prognozy i osiągnięcie Celu Sprintu.

To oznacza, że jeśli wyceny (w dowolnej formie) są częścią planu realizacji, empiryczne dostosowywanie tego planu do bieżącej sytuacji może (ale nie musi) wymagać zmiany oszacowań. Więcej: jeśli zmieniłby się plan, a nie zmieniałyby się oszacowania, na podstawie których była budowana jego poprzednia wersja, w niektórych przypadkach skutkiem będzie pogrążenie się developmentu w chaosie.

Dlatego też na pytanie, czy oszacowania związane z SBI, listami kontrolnymi, zadaniami itd. można zmieniać w trakcie Sprincie, odpowiedź jest twierdząca. Przypominam przy tej okazji, że mowa teraz nie o oszacowaniach elementów Backlogu Produktu, jakie są realizowane, ale o wycenach tego, z czego składa się plan ich realizacji.

Zupełnie osobną kwestią jest sensowność definiowania Backlogu Sprintu, jego elementów, planu działania itd. w sposób mocno zależny od oszacowań. Tak dzieje się zwykle wtedy, gdy Zespół (Developerzy w nim) próbują w trakcie Planowania Sprintu stworzyć kompletny harmonogram prac, z rozpisaniem na poszczególne osoby i nie jest to dobra strategia. Każde nieprzewidziane zdarzenie lub odkrycie problemu, o którym nikt nie wiedział na początku Sprintu, może wymusić lawinę zmian w dość misternej układance, jaką jest taki Backlog Sprintu.

Poza tym przyzwyczajony do realizowania planów Zespół może mieć spore trudności z poradzeniem sobie z sytuacją, w której nagle musi zacząć planować just-in-time, bo jeśli zmitręży sporo czasu na aktualizację planu (w tym wycen), może zabraknąć paru godzin albo i dni na development.

Zdecydowanie lepszym pomysłem jest posługiwanie się najlżejszą możliwą formą planów, które są wystarczające dla Developerów, a zarazem łatwe do zmian. Takie, które na pewno będą musiały być doprecyzowane lub modyfikowane w trakcie Sprintu, ale ta konieczność nie będzie dla nikogo zaskoczeniem, tylko wręcz stanowić będzie jedną ze składowych planu. To najczęściej idzie w parze z szacowaniem i prognozowaniem wystarczającym, ale nie wyczerpującym, czyli takim, które pozwala podjąć niezbędne decyzje, ale nie zmusza nikogo do prób precyzyjnego przewidywania przyszłości.

Do czego służą oszacowania?

Odpowiedź jest prosta: są pomocne przy podejmowaniu różnych decyzji, ale same w sobie nie niosą realnej wartości i faktycznej informacji. Nie opłaca się poświęcać na nie więcej czasu i środków, niż absolutne minimum, które pozwoli skutecznie zasilić procesy decyzyjne.

Zwykle elementy Backlogu Produktu szacuje się wiele razy w ich cyklu życia i odbywa się to na różne sposoby. Okazjonalnie może mieć sens takie szacowanie również w trakcie rozpoczętej już realizacji lub po jej zakończeniu, ale niekoniecznie zawsze warto to robić.

Wycen nigdy nie powinno się traktować jako miary wartości ani czynić z nich wiążących zobowiązań. I absolutnie nie powinno się estymować czegoś, co można sprawdzić empirycznie.

Wszelkie wyceny mają sens o tyle, o ile koszt ich uzyskania i ryzyko posłużenia się nimi są na tyle niskie, że nie przeważają nad korzyściami z ich posiadania.

Zadanie dla Scrum Mastera

Chęć „udoskonalania” oszacowań tak, by były one „precyzyjne”, często jest pochodną jakiegoś problemu w Zespole lub organizacji. Scrum Master w takiej sytuacji powinien ustalić przyczyny, dla których się to dzieje, bo poświęcanie czasu i wysiłku na nieracjonalne działania nie jest efektywne i nie sprzyja skutecznemu dostarczaniu wartości.

Bywa też i tak, że sposób szacowania i posługiwania się estymatami jest pochodną procesów, jakie obowiązują w organizacji. Inaczej mówiąc, Zespół robi coś, co nie ma sensu, bo oczekuje się od niego, by to robił. Wtedy również Scrum Master powinien poszukać sposobu na zdjęcie z Zespołu tego obciążenia.