W świecie agile estymacja kojarzy się głównie ze story pointami (SP), planning pokerem i ciągiem Fibonacciego.

Drugim skojarzeniem, zwłaszcza wśród osób nie będących developerami, to brak przełożenia na czas, a co za tym idzie odpowiedź na pytanie “kiedy to będzie gotowe?!”. Na potrzeby tego wpisu będę posługiwać się SP, ale problemy z prognozowaniem daty ukończenia pojawiają się bez względu czy wyceniamy w t-shirtach, SP czy jakimkolwiek innym “agile’owym” systemie.

Nie dziwie się, że spora część developerów nie chce szacować używając godzin, czy w najlepszym wypadku tygodni. 

Estymacja, zwłaszcza czegoś, co robi się po raz pierwszy to w zasadzie wróżenie z fusów. Odpowiedź na pytanie “na ile to wyceniasz?” jest też podszyta strachem; co jeśli wycenię źle? spóźnie się z robotą? czy będą konsekwencje? Oprócz tego, z momentem podania dat czy czasu trwania wiele osób zapomina, że jest to estymacja – czyli coś niestałego, założenie, które może się zmienić.

Developerzy, którzy chcą pracy w storu pointach często uważają, że dzięki nim obronią się przed odpowiedzialnością za czas trwania. W tym kontekście story pointy powinny pozostać czymś abstrakcyjnym, reprezentującym wysiłek, złożoność ale nie czas w rozumieniu godzin.

Co zrobić żeby nie wpaść w pułapkę problemów z prognozowaniem i estymacją?

Pułapka 1. Wiele sposobów wyceniania.

Zespół wybiera w jaki sposób estymuje. Jeśli zespół nie będzie rozumiał sposobu wyceny zadań

Znając system, np SP, upewniamy się czy wszyscy członkowie zespołu jednakowo rozumieją co reprezentują poszczególne punkty. Czy jest to stopień skomplikowania zadania? Czym różni się zadanie wycenione na 1SP od takiego na 5SP?

Jeśli zespół już to ustalił, trzeba zadbać o to w jaki sposób przypisywane będą punkty. Czy będzie to planning poker czy jakiś inny sposób. Ważne żeby był on z góry ustalony i zrozumiały dla każdego. 

Dla początkujących zespołów lub takich przywykłych do wyceny w godzinach polecam na początek sposób estymacji w pieskach, wiaderkach, koszulkach, orzechach (siema XP!). Im dalej od czegoś co przypomina czas – tym lepiej. 

Podczas wyceny na pewno pojawi się problem, kto ma wyceniać; jak to cały zespół przecież my nie wiemy co robią QA, a frontowiec nie wyceni backendu. Jest to typowy problem dla zespołów, które pracowały w silosach. I oczywiście, powyższe zdania są prawdziwe! W wycenie chodzi o dyskusje wszystkch członków zespołu. Jeśli pozwolicie na to, żeby to backend dyktował rozmiar zadań moze szybko okazać się, że mała zmiana na backendzie wymaga ogromnych testów, a wycena tego nie uwzględni. W efekcie zadanie okreslone na XS czy chihuahua w rzeczywistości będzie mastiffem i nie zostanie ukończone w sprincie. Podobna sytuacja jest wtedy gdy osoby z najwyższym seniority dyktują/wplywają na wycenę. Wszystko spoko, ale co jeśli zadanie wycenione przez seniora trafi do juniora?

Rolą SM jest wyłapanie tych sytuacji i moderacja dyskusji, żeby każdy się wypowiedział, każdy dopytał. I tak, jeśli zrobicie to całym zespołem będzie to trwało w nieskończoność, będzie męczące a po 40 minutach ludzie przestaną się skupiać i słuchać.

Dlatego podzielcie zespół na mniejsze, niech w każdej podgrupie będą reprezentanci różnych umiejętności/ ról. Podzielcie między nich zadania, które wycenią i efekty tej wyceny zaprezentują reszcie. Dzięki temy wyceny pójdą spawniej, a w mniejszej grupie trudniej pozostać na uboczu i się nie wypowiadać. Uważajcie na kliki! Dobierajcie ludzi losowo 🙂

Pułapka 2. Nie relatywność.

Ludzie są beznadziejni w ocenach, jeśli nie mają punktu odniesienia. Doskonale to widać w malarstwie, gdy perspektywa nie była jeszcze w użyciu. Życzę szczęścia temu, kto miałby układać taktykę zdobycia tego zamku na podstawie takiego obrazu… 

Tak samo jest z estymacją zadań. Jeśli siadacie do wyceny, bierzecie pierwsze zadanie z brzegu i będziecie chcieli przypisać mu jakąś wartość, to bez odniesienia się do innego zadania, wasza estymacja będzie z czapy i skończycie z absurdalnie wysoką bramą wjazdową, jak autor powyższego obrazu. Niestety spaczy to resztę estymacji, bo to pierwesze zadamnie stanie się punktem odniesienia. 

Chociaż znam przypadki, gdy każde zadanie było wyceniane w izolacji od poprzedniego, karuzeli śmiechu nie było końca gdy w backlogu spintu było mnóstwo zadań XL, były one “dowożone” i jeszcze zespół bał nową pracę… 

Dlatego tak ważna jest relatywność. Wypoziomowane wagi, ustalenie skali, która będzie naszym odnośnikiem. Im zespół bardziej zaprawiony w estymacji, tym będzie to łatwiejsze. Jednak ja i tak polecam kalibrację co jakiś czas.

Ciekawą opcją jest przeprowadzenie dry run, czyli wycenienie zdań, które już zostały zrobione i dyskusja. Celem tego ćwiczenia, jest zaznajomienie zespołu z estymacją relatywną, osiągnięcie zrozumienia co do skali w której zespól wycenia. Ćwicząc wycenę na zadaniach, które są już zrobione, pozbywamy się elementu niepewności co do wymagań, a skupiamy się tylko na obserwacji czy zadanie za 1 sp było większe od tego za 2sp i dlaczego. Dzięki temu, gdy zespół będzie pacował z nowymi zadaniami, będziemy moglli zapytać, jak takie nowe zadanie ma się do tych których wyceny zespół zna.

Uważam, że bardzo dobrym rozwiązaniem jest wizualizacja skali. Czy to w programie typu whiteboard, gdzie na osi X bedą naniesione wartości plus przykładowe zadania i zespół wyceniając będzie dokładał na tą oś nowe itemy, czy, jeśli pracujecie stacjonarnie używająć karteczek i tablicy.

Mając przed oczami duży obraz, łapiemy perspetywę – ułatwiamy sobie porównywanie. Jeśli nie będziemy wizualizować musimy cały czas moderować dyskusje i powracać do wcześniejszych wycen; “czy zadanie X na pewno jest takie jak Y?”, “hej, czemu daliśmy już zadaniom Y,Z,B taką wycenę, czy one na pewno są takie same?”. Jest to zwyczajnie tudniejsze i przeważnie SM ma tu najwęcej roboty. Jeśli mamy wizualizacje, wszyscy uczestnicy o wiele chętniej i częściej zwacają uwagę na rozbieżności.

Pułapka 3. Brak miejsca na niespodzianki

Nie da się nie pytać “na kiedy to będzie?”. Jeśli mamy produkt, który chcemy żeby zaczął zarabiać to musi on być udostępniony użytkownikom. Musi być na produkcji. Samo pytanie jest całkowicie normalne, jest prośbą i informacje. Inna sprawa to dlaczego budzi ono taki opór/strach/złość. To już jest związane z doświadczeniami danego zespołu, człowieka i z konksekwencajmi związanymi z odpowiedzią. Zostawmy na razie ten temat i skupmy się na tym, jak prognozować żeby nie bolało.

Ja proponuje używać trzech miar; cycle time, lead time oraz velocity. 

Zacznijmy od najłatwiejszej, która pozwala nam prognozować, w którym sprincie dana część backogu produktu, może zostać “podjęta”, czyli velocity. Prędkość. Co zorbić, żeby ją policzyć? Sumujemy ilość SP zrobionych i dzielimy przez ilość sprintów, lub inaczej sumujemy ilość historyjek zrobionych i dzielimy przez ilość sprintów. Wynik stanowi ilość SP do zrobienia na sprint, lub ilość historyjek do zrobienia na sprint. Jest to bardzo prosta średnia i mając mało danych, mały sprintów przerobionych mogą wyjść głupoty. Licząc velocity, jeśli macie sporo materiału moim zdaniem lepiej zrobić medianę, i wyłączyć z równania wartości skrajne – czyli te sprinty w których zrobiliśmy naprawdę dużo lub naprawdę mało. Problem z valocity jest taki, że jest to średnia, w 80% się sprawdzi przy naprawdę dobrych danych wejściowych (wg Pareto). Dlaego posługując się nią w rozmoawach z PO, stakeholderami czy zespołem planującym sprint, jako SM podkreslajcie ten 20% margines – albo zrobicie mniej o 20% albo więcej. Oznacza to nie ładowanie pod korek, nie robienie od razu wersji maksimum ale znowu… back to basics, wyznaczanie takiego celu/golu sprintu żeby był on osiągalny na wiele sposobów, żeby było miejsce na elastyczność jeśli pojawi się niespodzianka.

To samo w przypadku prognozowania backlogu produktu. Jeśli mówimy, że dana część backlogu może być zrobiona za X sprintów, to zdanie to ważne jest tylko teraz. W momencie gdy w backlogu pojawi się nowa rzecz, cały misterny plan, jak psu w …. no wiecie gdzie…

Velocity to drogowskaz, pomoc, ściągawka. To jest pisanie palcem po wodzie. Ślad jest, ale tylko przez chwilę. To pomoc, z której można skorzytsać w momencie gdy mówimy o przyszłości, gdy potrzebujemy punktu odniesienia – ale to nie jest plan! Velocity i oparte na niej prognozy to input do planowania, trzeba nałożyć na to jeszcze filtry capacity zespołu na dany sprint, czy zwykłe doświadczenie (gut feeling) i cały czas mieć w głowie, że musi być miejsce na niespodzianki.

Pułapka 4. Featury, które są ale ich nie ma.

W tym miejscu chce napisać o Cycle time i Lead time. Myślę, że z punktu widzenia managera to będą miary, które najwięcej powiedzą o tym kiedy dana rzecz będzie zrobiona. Dla developreów, nieraz, zrobione oznacza wypushowane gdzieś. Gdzie? czasem na jakieś środowisko testowe, czasem na produkcje. Zwłaszcza w firmach, gdzie mamy specjalizacje, silosy, gdzie proces end2end jest “zaciemniony”, tam właśnie zrobione będzie oznaczało, przerzucone przez płot dalej. I nara!

Cycle time i lead time pokażą nam gdzie zadania utykają i na jak długo.

Cycle time to najprościej data ukończenia zadania – data rozpoczęcia zadania. Jednorazowe sprawdzenie tej wartości nic nam nie da, trzeba ją monitorować na bieżąco i na bieżąco dodawać dane. Cycle time jest potrzebny do policzenia Lead Time, który pokazuje jaki czas jest potrzebny na zrobienie zadania od momentu otrzymania requestu od klienta (coś trafia do backlogu produktu) do ukończenia zadania.

Z punktu widzenia użytkownika/klienta powinniśmy dążyć do redukcji Lead Time i do tego często odnoszą się managerowie mówiąc, że coś trwa za długo. I nie ma co się temu dziwić, jeśli manager/zarząd słyszy od użytkowników/klientów, że oni już czekają na dany fearture ileś tam czasu, i że dokładnie mówili czego chcą, to manager/zarząd słyszy “coś jest dobrze zdefiniowane, tylko zespół jest za wolny”. Gdy pokażemy wtedy wartości Lead i Cycle time można zobaczyć, czy to procesy dotyczące programowania są za wolne czy może nasz backlog to zamrażalka i śmietnik.

Jeśli faktycznie backlog działa dobrze, i problem jest w Cycle time to możemy zacząć pracować z limitowaniem WIP, odpowiednią priorytetyzacją czy ulepszaniem refinementów, żeby do pracy wrzucać samo mięcho, które przynosi wartość. Jest wiele możliwości optymalizacji od procesów po narzędzia i techniki.

Cycle time i lead time będą bardziej precyzyjne w prognozowaniu w długim horyzoncie niż velocity, które przyda się bardziej jako wskaźnik przy sprint planningu.

Pułapka 5. Brak rozmowy.

Pułapek estymacji jest o wiele, wiele więcej jednak na ogólnym poziomie można sprowadzić je do braku dyskusji i nieweryfikowania założeń/przekonań. 

To jest trochę tak, jak z kolorami niebieski ma wiele odcieni i jeśli nie dopytamy co ktoś miał na myśli, zamiast z granatowym lakierem na aucie, skończymy z majtkowym niebieskim.

Jednym z narzędzi zabijających komunikacje jest… Jira. Nie wiem, jak to napisać żeby nie zostać źle zrozumianą. Wrzucając bardzo dużo szczegółów do Jiry zwiększamy pokusę, że autor albo odbiorca powiedzą, że nie ma co gadać, bo wszystko jest opisane. Tylko, że jak widzicie na przykładzie z kolorem niebieskim, słowa nie są dość precyzyjne. W zespołach z niskim zaufaniem na pewno pojawi się ta pułapka – każdy będzie chciał mieć dupochron i wszystko wypisane, najlepiej z każdym edge casem. Dzieje się tak dlatego, że nie mamy do czynienia z partnerstwem między IT a biznesem, a typową przepychanką i blame game, jeśli coś okaże się niezgodne z czyimiś oczekiwaniami. Tylko, że z oczekiwaniami pracujemy poprzez rozmowę i dopiero później dokumentacje jej wyników. Tu z pomocą przychodzą techniki np Three Amigos. Na początek opisu powinno być dokładnie tyle, żeby móc zacząć rozmawiać – im większa dokumentacja na początku, tym większe prawdopodobieństwo, że rozmowy nie będzie i tym większe prawdopodobieństwo, że rzeczy z tej dokumentacji będą źle zrozumiane lub po prostu pomięte/zapomniane.

Mam nadzieję, że ta wiedza będzie dla was przydatna i wymienione przeze mnie techniki będziecie mieli szansę zastosować sami.