Problemy z punktami

Szacowaniu – jednemu z największych katuszy w pracy dewelopera – poświęciłem jakiś czas temu dedykowany artykuł. Tym razem chciałbym zgłębić temat poziom niżej i przyjrzeć się jednej z najpopularniejszych, a na pewno najmodniejszej obecnie w IT technik estymacji – “Story Points”. Nazwa tej metody, bazującej na reprezentacji oszacowania zadania za pomocą liczb z (quasi)ciągu Fibonacciego, ograniczonych do 40 (czasem i do 100), nie doczekała się zgrabnego polskiego przetłumaczenia. Wybaczcie, nie zaproponuję swojego. Bo coś mi te historyjki w tym wszystkim nie pasują…

A jeśli już jesteśmy przy słownictwie, warto od razu wskazać na popularny błąd językowy i nazywanie przyznanych Story Points, wyceną zadania. Pojęcie wyceny tymczasem dotyczy na przykład nieruchomości, koni czy dzieł sztuki i jest zarezerwowane do określania wartości materialnej, zarazem jest terminem zakładającym znacznie większą dokładność, pewność co do podawanej informacji, aniżeli oszacowanie.

Kończąc jeszcze wątek próśb o wybaczenie, dodam, że nie będę tu szczegółowo się rozpisywał czym “Story Points” są, nadto o tym i w książkach, i w internetach. Sporo pisze o tym chociażby Mike Cohn, autor lektury obowiązkowej, Agile Estimating and Planning.

Z założenia – miało być łatwiej. Nie tylko deweloperzy są wszak słabi w szacowaniu, pod tym względem nie różnią się od reszty społeczeństwa. Przypomnijcie sobie wasz ostatni remont mieszkania. Kiedy miał się pierwotnie zakończyć? A jakie miały być koszty? 

Ktoś zatem w końcu pomyślał, że lepiej nam, ludziom, wychodzi porównywanie, nawet w kontekście tematów mniej lub bardziej abstrakcyjnych. Szczególnie, jeśli rozbijemy duże działanie na mniejsze zadania. Przykładowo – nie jesteśmy w stanie dokładnie stwierdzić w jakim czasie zaimplementujemy integrację naszego systemu z systemem A, ale patrząc pobieżnie na system A i mając doświadczenia z pracy z analogicznym systemem B, wiemy, że ryzyko jest podobne, poziom skomplikowania także, i, tak na oko, będzie to dwa razy mniej roboty. Stąd zadanie z systemem B powinno być oszacowane na dwa razy większą liczbę punktów, niż to dotyczące systemu A. Do tego zaproponowano, a właściwie to w końcu skutecznie przebito się z wiedzą, że w estymowaniu nie bierzemy pod uwagę tylko pracochłonności – czasu potrzebnego na realizację zadania – ale również poziom skomplikowania i niepewności – ryzyka (uświadomienie sobie ile nie wiemy, albo w jak głębokie bagno wchodzimy). Cóż, lepiej późno niż wcale.

I tak do IT trafiły Story Points, przypomnieliśmy sobie o ciągu Fibonacciego, rozgorzały zaciekłe dyskusje czy 20 jest lepsze niż 21, czy powinno się dopuścić “połówki” i zera, czym jest “kawa”, czy 13 może w ogóle trafić na backlog sprintu, czy skala powinna się kończyć na 40 czy 80… W wielu firmach pojawiły się też powszechne głosy oburzenia, że wszedł ten agile i deweloperzy zamiast pracować grają w karty, do tego podobno w pokera. Ktoś nawet widział pieniądze na stole, a że w IT stawki duże…

Technika ta przyniosła wszakże wiele dobrego, wraz ze wspomnianym Planning Pokerem spowodowała, że zaczęliśmy w IT więcej o wymaganiach rozmawiać i patrzeć na nie z zupełnie różnej optyki. Do głosu dopuszczeni zostali nawet testerzy, ba w czasie realizacji zadań faktycznie zaczęto uwzględniać czas potrzebny na testy! Problemy zaczęły wypływać na powierzchnie szybciej, znajdowano lepsze rozwiązania i wypracowywano konsensus spornych sytuacji. 

Z drugiej strony, jak to zwykle bywa, pojawiła się cała masa problemów, wynikających z niezrozumienia lub wypaczenia samej idei. O tym ciekawie napisał ostatnio Ron Jeffries, który jak sam mówi:być może wymyślił ideę Story Points, za co teraz przeprasza. Może lekko przesadził, ale włos się czasami na głowie jeży…

Z jakiego powodu? No właśnie. Chciałbym skupić się teraz na często popełnianych błędach przy pracy z punktami. Problemach, które są przeze mnie obserwowane, niemalże na co dzień

  1. Lepsze wrogiem dobrego

Story Points często wprowadzane są do pracy zespołów deweloperskich mechanicznie. Z mylnym podejściem, że tak każe Scrum. Niesamowite jak powszechnie technika ta traktowana jest jako jedyny dopuszczalny sposób szacowania w Scrumie. No dobra, uważa się, że dopuszczalne są jeszcze jej wariacje, gdzie zamiast punktów stosuje się rozmiary koszulek, a w co bardziej wyluzowanych firmach podobno wykorzystuje się rodzaje psów (zadanie A to sarenka, a zadanie B wilczur) czy alkoholowej zastawy (zadanie C to pięćdziesiątka, a zadanie D małpka). Podobny syndrom jest z User Stories, ale o tym przy najbliższej okazji. Skąd to się bierze, to też temat na inny tekst.

Sęk w tym, że często nie zważa się na to, jak osoby pracujące w zespole szacowały wcześniej, jakie zwyczaje istniały w firmie, czy to było dobre czy złe. Z całym dobrodziejstwem zwinnego inwentarza – spotkań, ról, etcetera, etcetera, wprowadzane są i punkty.

A zatem mamy tu klasyczny syndrom scrumowej policji czy wyświechtanego kultu cargo (ile razy jeszcze będziemy oglądać to na prezentacjach na konferencjach, z zawsze tym samym zdjęciem na slajdach?). 

Zatem, zanim, jako Scrum Master, zdecydujesz o wprowadzeniu w zespole punktów, przyjrzyj się co w zespole działo się do tej pory lub – jeśli zespół jest nowy – porozmawiaj z ludźmi jakie dotychczas mieli doświadczenia z szacowaniem.

Najistotniejsze w tym wszystkim jest to, żeby doprowadzić do tego, żeby szacowali rzeczywiście ci, którzy będą przy tym zadaniu pracowali – opracowywali koncepcję, programowali, testowali. I – żeby robili to wspólnie i dali wspólną, jedną informację.

A zatem – dosyć “szacowania eksperckiego” (które dokonywał kiedyś tzw. Ekspert IT), cedujemy ten proces na zespół. I oczekujemy dogłębnej dyskusji o samym zadaniu, ale także o jego oszacowaniu. A jak już to się będzie odbywało, doprawdy nie ma znaczenia. Pod kilkoma wszakże warunkami – wybrany sposób musi być czytelny dla Product Ownera i interesariuszy, zlecających zadania, zrozumiały w całej organizacji. A także – sposób ten musi być po prostu skuteczny i wiarygodny, wspomagać przewidywalność pracy zespołu.

Doprawdy – nie trzeba wprowadzać zasad relatywności, niekonieczne są piękne laminowane karty do planning pokera, wciąż można całym zespołem szacować w roboczogodzinach. Liczą się efekty.

2. Czy punkty są w ogóle potrzebne?

Szacowanie w wersji zwinnej jest drogie – angażuje czas całego zespołu, i to w sporej ilości. Warto pamiętać o tym, że jest to pewna inwestycja, koszt – zabieramy czas, który można by poświęcić na sól pracy – deweloperkę. A co zyskujemy w zamian? Trzeba zadać sobie to pytanie i przedyskutować z Product Ownerem i zespołem do czego jest nam potrzebna wiedza czy dane wymaganie opatrzone zostanie piątką czy ósemką?

Ułatwienie priorytetyzacji, liczenie ile możemy wziąć na sprint, narzędzie pomocnicze przy konieczności podania ile zadań zrealizujemy w zadanym czasie przy okazji większych inicjatyw  – to chyba najpopularniejsze powody. Są i inne.

A teraz zadajmy następujące pytania:

Jeżeli konkretne zadanie ma w danej chwili najwyższy priorytet, to czy faktycznie jest sens je szacować? 

Po co szacować zadanie, które trafia do najbliższego sprintu jako jego cel?

Czy wszystkie zadania w sprincie muszą być wyestymowane?

Czy faktycznie liczenie prędkości pracy zespołu nam w czymkolwiek pomaga? Czy przypadkiem zamiast na dokładnym planowaniu pracy, nie skupiamy się na liczbach?

Zastrzegam przy tym – rozróżniajmy sam proces szacowania od rozmowy o wymaganiu. To pierwsze niekoniecznie musi się odbywać, to drugie – zawsze.

Zachęcam do przeprowadzenia porządnej analizy – co nam te punkty dają, gdzie je wykorzystujemy. Jeśli chcemy z nich zrezygnować (całościowo lub tylko częściowo), z reguły pojawia się dodatkowy problem wynikający z szerszych zasad środowiska, w którym działamy czy oczekiwań menedżmentu. Do tego wątku wrócę na koniec tekstu.

Sądzę, że warto jeszcze wspomnieć o #noestimates. To idea mówiąca o całkowitym porzuceniu estymat na rzecz maksymalizacji dostarczanej wartości, działając przy ograniczonym czasie lub budżecie. Czysto zwinne, dosyć idealistyczne, ale nie utopijne podejście. Namawiam do poczytania o nim.

3. Zależy kto to będzie robił

Zespół rozmawia o zadaniu, dochodzi do jego oszacowania i w którymś momencie pada ze strony jednego z deweloperów:

  • Liczba punktów zależy od tego, kto będzie to zadanie robił.
  • Jak to? – pyta zatroskany Product Owner.
  • Gienek i Lucek jeszcze nigdy nic nie robili w tej części systemu, a jest ona skomplikowana i słabo udokumentowana. Adelajda mogłaby to zrobić kilka razy szybciej, bo zjadła na tym zęby.

O czym ta wymiana zdań świadczy? Tylko i wyłącznie o tym, że temat Story Points nie został w zespole należycie przepracowany, a jego członkowie nie rozumieją z czym mają tu do czynienia.

Natomiast jest to jedna z najczęściej spotykanych sytuacji i chyba najczęstszy z błędów, o których piszę.

Deweloperzy utożsamiają tu Story Points z czasem wykonywania prac. Wiedzą, że Adelajda upora się z zadaniem szybko, podczas gdy pozostała dwójka spędzi dodatkowy czas na analizie i konsultacjach, jak i nad samym rozwiązaniem. I tak, w efekcie, jeśli to Lucek lub Gienek będą realizować zadanie, oszacowaliby na 8kę, a jeśli Adelajda to 2kę. Załóżmy, że do zadania przypisywana jest ta ostatnia (bo przecież trzeba pędzić i realizować zadania z backlogu), zatem dopisywana jest 2ka. Kiedy przychodzi do realizacji Adela rozchorowała się, więc do całości siada Gienek i po tygodniu pracy wszyscy zastanawiają się kto tak nisko to wyszacował…

Tymczasem Story Points jest miarą całkowicie abstrakcyjną, której nie powinno się w żaden sposób porównywać do czasu, próbując przeliczać je na godziny, a następnie kalibrować. 2 Story Points oznacza nic innego, jak to, że zadanie jest mniej więcej, na oko, 2 razy większe, wymaga dwa razy więcej wysiłku – biorąc pod uwagę trzy czynniki: czas wykonania, poziom skomplikowania i ryzyko – niż zadanie, któremu przyznano 1 Story Point. I tak samo, że jest, mniej więcej, na oko, cztery razy mniejsze, niż zadanie wyestymowane na punktów 8. Koniec końców przekłada się to nam na czas dostarczenia rozwiązania, przykładowa 2ka powinna być szybciej dostarczona niż 5tka. Natomiast nie możemy ulegać pokusie typu 2ka – 6 godzin, 5tka około 15 godzin, bo to by oznaczało że pod uwagę jest brany wyłącznie czynnik czasowy

Nie powinniśmy brać pod uwagę na etapie szacowania tego, kto będzie to zadanie realizował (ma to swoje uzasadnienie doprawdy rzadko). Czy siądzie do tego Lucek czy Adelajda, jeśli zadanie ma 2 SP, to ich wysiłek będzie po prostu dwa razy większy niż w analogicznym zadaniu oszacowanym na 1 punkt. Przy czym ilość czasu potrzebna na jego realizację może być całkowicie różna w zależności od tego kto to będzie realizował. Jedna osoba może zadanie na 1 SP realizować w 4h, a inna w 14h. Dziwne? Tylko, gdy próbujemy te punkty przeliczać na czas. Między innymi właśnie po to punkty zostały wprowadzone, żeby uniknąć jałowych dyskusji deweloperów czy realizacja zadania zajmie 4h czy 14h, gdzie ilość tego czasu zależy od doświadczenia, umiejętności, wiedzy, stażu w firmie. Wprowadzając wartość abstrakcyjną – dyskutanci mogą ustalić jeden punkt odniesienia i nazwać go np. 1 SP.

W programowaniu jesteśmy przyzwyczajeni do podawania orientacyjnego czasu wykonania zadania. Stąd naturalnym jest, że i punkty utożsamiamy z czasem, a w konsekwencji ich liczbę uzależniamy od tego, kto zadanie będzie realizował – jeden zrobi to szybciej, drugi wolniej. Często takie działanie jest też symptomem dużych różnic w umiejętnościach w zespole czy też ścisłej specjalizacji i małej wymienności między deweloperami w stosunku do realizowanych zadań. Bądź też przyzwyczajenia do typowo samodzielnej pracy, odbywającej się pod płaszczykiem działań zespołowych.

Odseperowanie oszacowania w punktach od czasu i od tego kto będzie dane zadanie wykonywał, jest jednym z podstawowych warunków, żeby punkty miały w ogóle prawo zadziałać.

4.  To jest tylko dla backendu

Kolejną powszechną, a błędną, sytuacją, jest szacowanie dokonywane wyłącznie przez członków zespołu o danej specjalizacji albo wręcz jednej osoby, ponieważ tylko jego/ich to dotyczy. Ma to najczęściej miejsce w przypadku zadań technicznych – typowo refaktoryzacyjnych, zgłaszanych przez samych deweloperów.

Jest to rozwiązanie niezwykle kuszące, bo szybkie. Nierzadko zespoły wręcz oczekują, żeby autor danego zadania technicznego od razu je wyszacował. Takie oczekiwania najczęściej wędrują w stronę testerów, bo deweloperom zwyczajnie nie chce się słuchać o planowanych przez nich zadaniach, przykładowo związanych z testami automatycznymi. Tak samo javowcom nie chce się słuchać gadaniny osób od “widoków” o dostosowaniu kodu do nowej wersji ECMAScript, a osobom pracującym przy “widokach” o optymalizacji pamięci w PHP. Jako argumenty przeciwko wspólnej dyskusji o tych zadaniach padają najczęściej I tak nie będę tego robił / Przecież to robota Heniutka  / Przecież ja kompletnie tego nie rozumiem, po co mam tego słuchać lub i wprost: To w żaden sposób mnie nie dotyczy i nie interesuje.

Co tracimy działając w ten sposób? Przede wszystkim wspieramy podziały specjalizacyjne zespołu i zamykanie się w swoich “obozach”. Legitymizujemy i utwierdzamy myślenie typu: to nie moja technologia/specjalizacja, nie moja sprawa, które potem odbija się czkawką w różnych innych aspektach prac. Nie budujemy zrozumienia co do tego, co robi kolega/koleżanka siedzący obok. Dokładamy swoje cegły do już istniejących murów.

Eliminujemy wspólne dyskusje, możliwość skonfrontowania tematów z zupełnie innym podejściem, myśleniem, specyfiką pracy. Znika też okazja do przepływu wiedzy, nie tylko technicznej, ale i tej podstawowej – nad czym pracuje kolega/koleżanka z zespołu.

Niechęć do słuchania co robią osoby o innej specjalizacji (z tego samego wszak zespołu), epatowanie znużeniem przy opowieściach o szczegółach technicznych ich zadań czy głośne marudzenie o stracie czasu są – niestety – dosyć powszechne. Warto je przełamywać i zachęcać do wspólnego szacowania, rozmów o zadaniach, nawet jeśli dotyczą tylko jednej konkretnej technologii, którą w zespole zna tylko jedna osoba. Oczywiście trzeba też dbać, żeby autor zadania omawiał je w sposób zrozumiały dla innych, może bardziej ogólnie, z czytelnymi porównaniami. Już sama konieczność takiego przedstawienia zadania, aby zrozumiały je osoby na co dzień niezwiązane z daną technologią, może przynieść dodatkowe pomysły.

Warto wspólnie rozmawiać i szacować wszystkie zadania, niezależnie od ich rodzaju, budować w zespole wiedzę o tym co się dzieje, co i dlaczego robią poszczególne osoby i z czym to się wiąże… Niekoniecznie trzeba tak robić zawsze, ale należałoby do tego dążyć. A jeśli już robimy w tym jakiś wyłom, zadbajmy, żeby potem osoba, która wyszacowała jakiś zestaw zadań, w kilku zdaniach opowiedziała o nich w zespole.

5.  Zsumujmy punkty

Zdarzało mi się obserwować zespoły, które tworzyły finalną liczbę Story Points dla zadania, sumując wartości przyznane przez poszczególne grupy kompetencyjne w nim występujące. Czyli – dane zadanie programiści oceniali na 5, testerzy na 2, i koniec końców przy zadaniu widniała 7ka (lub 8ka, jeśli ktoś usilnie trzymał się ciągu Fibonacciego). Widziałem to i na większą skalę, np. backendowiec piszący w Pythonie przyznał 5, deweloperzy piszący “poziom wyżej” dodali 3kę, JSowiec dał 1, osoba odpowiedzialna za widoki 2, a tester 3. W sumie 14 punktów. Spotkałem się także z zespołami, gdzie i wartości per specjalizacja były zapisywane, i wykorzystywano prędkość specjalizacyjną, która definiowała ile punktów na sprint mogli wziąć dani specjaliści

Na pytanie – dlaczego tak – najczęściej słyszałem, co gorsza, od Scrum Masterów, że przecież przy takiej ilości kompetencji inaczej się nie da. Że próbowali inaczej, ale nie wychodziło. Przecież to inne technologie, każdy robi swoją część, inni nie do końca to rozumieją, a tak jest łatwiej, wygodniej i jeszcze do tego dokładniej.

O czym to świadczy? Ano najczęściej o tym, że znów mamy zatem sytuację analogiczną jak w poprzednim punkcie. Każdy zamyka się w swoim grajdołku, osłania parawanem i kompletnie nie interesuje go nic, co dzieje się wokoło. Każdy przyznaje punkty według własnej skali i w żaden sposób nie ma w zespole porozumienia, próby ustalenia tego czym jest 1 SP dla zespołu. Istnieje tylko 1 SP dla testera, który jest czymś zupełnie innym niż 1 SP dla JSowca. Nie ma też próby zrozumienia tego, co robią osoby o innych specjalizacjach i nie dziwota, że jeśli się takim zespołom przyjrzymy – najczęściej okaże się, że nie istnieje tam zespołowość w kontekście wspólnej pracy, a ta wygląda po prostu kaskadowo i  jest realizowana etapowo przechodząc po kolei z jednych rąk do drugich.

Efektem tego szacowania jest też często jego niedokładność.

Bez dwóch zdań powinniśmy dążyć do określenia zespołowych miar Story Points. Im więcej w zespole zróżnicowanych kompetencji, tym trudniej to wypracować. Chcąc używać wszakże w tego typu zespole tego sposobu szacowania, nie mamy innego wyjścia. To też jeden z warunków do zbudowania prawdziwego zespołu, a nie zestawu ludzi działających przy jednym backlogu.

Szacując zadania w tego typu zespołach, zawsze powinniśmy zacząć od ilości kompetencji, jakie będą potrzebne w ich realizacji. Już samo to, da nam pewien ich obraz. Im więcej osób trzeba będzie zaangażować, tym estymata powinna być wyższa. Następnie, każdy ze specjalistów powinien wszystkim opowiedzieć, co dokładnie będzie realizowane, jakie mogą wystąpić według nich problemy, jakie są niewiadome. Po omówieniu całości zadania, wszyscy będą mieli pełen obraz sytuacji. I mogą pokusić się o wspólną estymatę.  Im więcej takich rozmów, tak wyszacowanych zadań, tym będzie prościej.

6. Szacuje się tylko na Doskonaleniu Backlogu

Innym z dosyć rozpowszechnionych mitów związanych ze Story Points jest to, że proces szacowania zadań powinien odbywać się wyłącznie w czasie spotkań doskonalenia backlogu.

Nierzadko obserwuje, że szacowanie potrafi zająć nawet i połowę takiego spotkania. Z reguły estymacja następuje zaraz po omówieniu zadania, a to czego zespół nie zdąży przerobić, jest odpowiednio oznaczane i trafia na następne… W efekcie rośnie górka zadań do omówienia, a zaproszeni goście (eksperci, interesariusze) i Product Owner niejednokrotnie siedzą jak na tureckim kazaniu, słuchając dyskusji na temat niskopoziomowych szczegółów implementacyjnych.

A i owszem, ma to swoje plusy! Zadania szacowane są “na świeżo” po ich szerszej analizie, a i obecność Product Ownera czy interesariuszy może wnieść dodatkowy punkt widzenia.

Niemniej jednak, skoro decydujemy się na doskonalenie backlogu w formie spotkania, to skupmy się tu przede wszystkim na omówieniu przygotowanych na spotkanie zagadnień. Zadbajmy o efektywność spotkania i czas naszych gości, estymacja jest jednak zadaniem stricte deweloperskim. 

Sam najczęściej proponuję zespołom szacowanie zaraz po Daily Scrum. Chwilowe pozostanie po spotkaniu, np na. 5 minut, i w tym czasie omówienie zadań z kolejki “czekających na estymatę” wraz z wspólnym przyznaniem im punktów. Sposób ten postrzegam jako szybki, sprawny, a zatem –  efektywny. Nie, nie widzę niczego złego w szacowaniu na spotkaniach, na których rafinujemy backlog w szerszym gronie. Niemniej jednak proponowałbym ograniczać je tam do minimum.

7.  Szalone liczby

  • Co Pan tutaj proponuje? Jak to? My potrzebujemy punktów!
  • Mamy problem z efektywnością zespołów. Jedni robią 40 punktów na Sprint, podczas gdy inni potrafią nawet 90. Jak sobie z tym poradzić? Jak tych słabszych dociągnąć do lepszych?
  • Jak wyliczyć prędkość zespołu w sprincie, gdy są urlopy? Jak wtedy dobrze narysować wykres spalania?
  • A tu własnie ten wykres, na którym liczymy ilość punktów realizowanych przez poszczególne osoby w zespole, proszę spojrzeć…

To tylko część cytatów, które zapewne znalazłyby się na kartach neopozytywistycznej noweli Z pamiętnika zwinnego konsultanta (aż się prosi dodać, nawiązując do Sienkiewicza – poznańskiego – z tego miejsca pozdrawiam koleżanki i kolegów po piórze z całodobowego agile’a, siedem dni w tygodniu).

Tekstu masa, ja tu gadu, gadu, pozwalam sobie nawet bajdurzyć, że punktów można czasami w ogóle nie liczyć, że można w koszulkach, a przecież wciąż niemało jest firm, gdzie Scrum Master kompletnie nie może sobie na coś takiego pozwolić, a zasady działania z punktami są ściśle opisane i kontrolowane przez Kogoś Ważnego. I nie ma od nich odstępstw.

Ileż to wciąż na konferencjach rozżalenia i frustracji z tym związanej – czasem jawnej, prezentowanej na slajdach i omawianej, a czasem tylko tej kuluarowej. Menedżerowie porównujący i oceniający wydajność zespołów, poprzez patrzenie na ich punkty, niedopuszczający do jakichkolwiek odstępstw od kanonicznych reguł szacowania, dopytujący co się dzieje, gdy tylko wykres spalania nie wygląda wzorowo, tworzący presję gdy prędkość zespołu odbiega od wyznaczonych norm…

Któż ze Scrum Masterów nie ma takich doświadczeń.  Wielu na pewno zaliczyło coś na kształt słynnej “suszarki Fergusona” z Manchesteru, kiedy próbowało prosić o wybaczenie, nie o zgodę, w kwestie samodzielnie podjętych decyzji związanych z punktami. Ja mam to za sobą, kto jeszcze, palec do budki!

Skąd to się bierze? Zespół nie stosuje punktów, nie szacuje jeśli nie musi (ma ustalone priorytety, dokładnie rozpisuje podział prac przy planowaniu), pracuje szybko, regularnie dostarcza wartość, Product Owner jest zadowolony. W pewnym momencie jednak ktoś gdzieś tam zauważa, że wykres tego zespołu wygląda inaczej niż u innych, że liczba punktów i prędkość wynosi 0. I robi się z tego afera. Następne dwa tygodnie zespół spędza na uzupełnianiu cyferek przy swoich zadaniach, a motywacja dziwnym trafem jakoś spada. Znacie? To posłuchajcie.

Takie i wyżej opisane sytuacje są tylko i wyłącznie emanacją tego, że gdzieś w firmie coś nie funkcjonuje, jak powinno. Że my się tu bawimy w jakieś agile, a nie zadbaliśmy o odpowiednią komunikację i zbudowanie poczucia bezpieczeństwa i zaufania do nas oraz całej tej magii, którą wprowadzamy, u osób, którzy nas z tej pracy rozliczają. Albo dopiero rozliczą.

Nie uda się rozwiązać problemu, jeśli nie porozmawia się z osobą, która określonych danych potrzebuje i nie dotrze się do tego, do czego w zasadzie są one potrzebne. A przede wszystkim – kto tak naprawdę tego potrzebuje? Bo często jest tak, że rzeczywisty odbiorca danych znajduje się 30 pięter wyżej lub na zegarku ma godzinę wcześniejszą o 8 godzin. Trzeba to wszystko dobrze przepracować, wyjaśnić, próbując zrozumieć i zaadresować potrzeby drugiej strony. Nie stanie się to wszystko od razu, konieczne jest, jak wspomniałem, zbudowanie zaufania i wzbudzenie poczucia bezpieczeństwa u określonych osób. Bądźmy cierpliwi.

Na koniec

Technika szacowania w Story Points nie jest tak prosta, jak się wydaje. Ba, im bardziej wchodzimy w szczegóły, próbujemy ją wyjaśnić, tym bardziej okazuje się, jak to wszystko jest złożone. Śmiem twierdzić, że niewiele zespołów deweloperskich, umiejętnie, świadomie ich używa, w pełni korzystając z ich profitów. Z pozoru banalna technika kryje w sobie wiele pułapek, nieoczywistości, rzeczy wymagających dokładnego wytłumaczenia. To zadanie dla nas, Scrum Masterów.

Również do Scrum Masterów należy ocena czy metoda ta jest faktycznie właściwa, najbardziej odpowiednia dla danego zespołu, czy może powinien on stosować inne, być może “klasyczne sposoby”. A może w ogóle szacowanie nie będzie potrzebne?

Co charakteryzowało najlepiej szacujące w Story Points zespoły, które obserwowałem? To, że momentalnie tę technikę chwyciły, z miejsca wydawała się dla nich stworzona i po prostu naturalna. Bez zbędnej teorii, szybko chwytali nieuchwytne, od razu wiedzieli czy coś jest 5ką czy 8ką. Do tego byli po prostu pełni energii do pracy, zgrani, a w powietrzu unosiła się dobra atmosfera. Przypadek? Nie sądzę.

W artykule wymieniłem siedem problemów, z którymi ja sam najczęściej się spotykam i które mnie najbardziej uwierają. Ale ich spektrum jest znacznie szersze, niewykluczone zatem, że do tematu wrócimy jeszcze na naszych łamach.

#ScrumMaster#StoryPoints#szacowanie