Znormalizowane Story Points w SAFe – jak i dlaczego?

SAFe4 proponuje, aby Story Points w ramach tworzenia produktu były zunifikowane między różnymi zespołami. SAFe oferuje metodę, dzięki której można szacować Story Points już w pierwszym Sprincie. Z perspektywy Scrum takie podejście wydaje się początkowo niespójne z ideą Story Points. Aby rozwiązać tę sprzeczność, przyjrzyjmy się tej idei nieco bliżej.

Czym właściwie są Story Points?

Story Points to, krótko mówiąc, arbitrarna miara do kwantyfikowania nakładu pracy nad Backlog Item. Mają pomagać deweloperom lepiej planować pojemność – a Product Ownerowi dają rozumienie tego, co jest osiągalne w nadchodzących tygodniach i miesiącach. Dzięki temu można na przykład przewidywać terminy i zakres dostawy w ramach Release.

Dodatkową korzyść proponuje Mike Cohn: jeśli zna się Velocity i miesięczne koszty zespołu, można prowadzić szacowanie kosztów Backlog Items. W ten sposób można optymalizować ekonomiczność procesu wytwarzania. Na przykład Backlog Item może wydawać się nieekonomiczny, gdy znane są jego koszty. Dzięki temu Product Owner może wcześnie zdecydować, czy dana historia powinna być przerobiona, czy całkowicie odrzucona.

SAFe nawiązuje do tej idei w koncepcji WSJF: preferowane powinny być funkcje o najlepszym stosunku kosztów do korzyści.

Najważniejszą przesłanką, aby takie podejście mogło działać, jest to, by wszyscy uczestnicy mieli jednakowe rozumienie Story Points. Ponieważ Story Points mogą mieć dla różnych zespołów nieco inne znaczenie, należy zachować ostrożność przy analizowaniu wartości poza zespołem.

Czym są znormalizowane Story Points?

W SAFe jednostką wytwórczą dla produktu jest Agile Release Train (ART) – „Zespół zespołów".

Równie ważne jak w Scrum jest to, by wszyscy uczestnicy w zespole jednakowo rozumieli Story Point, w SAFe jest to, by wszyscy uczestnicy w ART jednakowo rozumieli Story Point.

Gdyby zespoły interpretowały Story Points różnie, Product Manager otrzymywałby zupełnie różne szacunki w zależności od tego, który zespół oszacował dane Item. Tak powstałe szacunki byłyby z perspektywy biznesowej zupełnie bezużyteczne. Tym samym cały proces szacowania byłby bezużyteczny, a szacunki bezwartościowe.

Dlatego SAFe proponuje, że tak jak w Scrum Team potrzebne jest wspólne rozumienie Story Points, tak też poszczególne zespoły w ART potrzebują wspólnego rozumienia Story Points, by sensownie szacować.

Dlaczego indywidualne Story Points na zespół to zły pomysł?

W SAFe wszystkie zespoły w ART dzielą jeden, wspólny, centralny Program Backlog. Ten Program Backlog konsoliduje wszystkie działania ART, niezależnie od tego, który zespół faktycznie later przejmie pracę.

Kluczową koncepcją zwinności jest to, że praca powinna być niezależna od osoby – gdyż specjalizacja prowadzi do lokalnej optymalizacji.

Z perspektywy Lean często lepiej jest, gdy wolniejszy zespół natychmiast przystępuje do pracy, zamiast czekać na szybszy zespół przy ważnych sprawach.

Szczególnie gdy kilka zespołów współpracuje, wolniejszy zespół może często dostarczyć część wartości, zanim szybszy zespół stanie się dostępny, by się włączyć. Dzięki temu skraca się całkowity czas dostawy i zaangażowanie szybszego zespołu do ostatecznego ukończenia.

Gdy Story Points między zespołami są różne, każdy pojedynczy Backlog Item musi być oszacowany przez każdy pojedynczy zespół, aż zrozumie się, który zespół kiedy mógłby skończyć. Jest to oczywiście możliwe, ale oznacza masowe marnotrawstwo i nadmiar.

Gdy natomiast Story Points są znormalizowane ponad zespołami, potrzebne jest tylko jedno szacowanie przez jeden zespół. Patrząc wtedy na Velocity poszczególnych zespołów, szybko i łatwo widać, ile czasu by to zajęło.

Dodatkową korzyścią ze znormalizowanych Story Points jest: gdy Zespół A potrzebuje wsparcia Zespołu B, by osiągnąć ważny deadline, Product Owner Zespołu B od razu wie, ile Zespół B musiałby wykreślić ze swojego Backlogu, by przejąć Stories Zespołu A – ponieważ nie ma potrzeby ponownego szacowania, nie powstają ani opóźnienia, ani nakłady na szacowanie.

Jak dokładnie SAFe normalizuje Story Points?

W pierwszym Program Increment ART jest nowy. Ani poszczególne zespoły, ani osoby w ART nigdy nie pracowały razem w dokładnie tej konstelacji. Zespoły są w „Fazie Storming" – podobnie jak sam ART.

Oznacza to, że Working Agreements są jeszcze niejasne. DoD to mgliste ideał, który nigdy nie był sprawdzony w praktyce. Wszędzie mogą czyhać pułapki. W zależności od przebiegu procesu wytwarzania środowisko pracy też jest pewnie nowe i nieznane. Wszyscy są na białej plamie na mapie – każde szacowanie to wróżenie z fusów.

Jednym z możliwych podejść byłoby teraz wspólne dyskutowanie o tym, którą historię wybrać jako punkt odniesienia, jak definiować punkty, ile punktów dostaje historia referencyjna – a potem pracuje się od tam. Ta dyskusja prowadzi do kolejnych dyskusji, które wszystkie same w sobie nie stanowią żadnej wartości z perspektywy klienta.

SAFe unika tego podejścia i proponuje: szacowanie relatywne.

W pierwszym PI Planning zaczyna się od tego, że zespół wybiera najmniejszy item ze swojego Backlogu i przypisuje mu „1". Następnemu większemu itemowi przypisuje się „2" i porusza naprzód, korzystając z ciągu opartego na liczbach Fibonacciego (1,2,3,5,8,13,20,40,100): Czy mamy item tej samej wielkości co znany item? Jeśli tak, dostaje tę samą liczbę – jeśli jest dotąd największy, dostaje odpowiednią liczbę. Jeśli nie mamy dobrego punktu odniesienia i musimy przeskoczyć, „3" byłoby co najmniej dwa razy większe niż „1", a „8" co najmniej dwa razy większe niż „3" itd. W ten sposób przez bardzo proste podejście bez dokładnej wiedzy można wypracować ocenę tego, co czeka zespół.

To oczywiście czyste zgadywanie i wartości są dość nieprecyzyjne. Ale ponieważ nie mamy jeszcze doświadczeń, to podejście jest tak dobre jak każde inne. Najważniejsze jest to, by podczas omawiania Stories zespoły rozmawiały o „Co", „Dlaczego" i potencjalnych ryzykach.

Jak oblicza się Velocity przez znormalizowane Story Points?

Podkreślmy jeszcze raz: w pierwszym Program Incrementie nie mamy pojęcia, ile Story Points zespół faktycznie zrobi. Ponieważ mamy jednak szacowania w osobodniach, SAFe proponuje następujące podejście w pierwszym PI Planning:

Wiemy, ilu członków ma nasz zespół. Wiemy też, przez ile dni w iteracji planujemy przychodzić do pracy (oczywiście nie wiadomo, kiedy ktoś zachoruje – to ryzyko po prostu pozostaje).

Typowa iteracja SAFe trwa 2 tygodnie kalendarzowe, czyli ma 10 dni roboczych. Tę liczbę można pomnożyć przez liczbę członków zespołu:
Podstawowa Pojemność = 10 * Członkowie Zespołu

Od tego odejmujemy dni, gdy członkowie zespołu są nieobecni:
Dostosowana Pojemność = Podstawowa Pojemność – (Dni Wolne * Członkowie Zespołu) – (Pojedyncze Dni Nieobecności)

Od tego odejmujemy jeszcze 20 procent – bo planowanie na 100% obciążenia zawsze kończy się katastrofą!
Wstępna Velocity = Dostosowana Pojemność * 0,8

Oto przykład:
Zespół Trolls składa się z 6 deweloperów. W kolejnej iteracji jest jeden dzień wolny, a Toni musi w piątek załatwić prywatne sprawy.

Podstawowa Pojemność = 106 = 60 SP
Dostosowana Pojemność = 60 SP (Podstawa) – 16 SP (Dni Wolne) – 1 SP (Nieobecność) = 53 SP
Wstępna Velocity = 53 SP * 80% = 42 SP

Zespół Trolls zaplanowałby wtedy Iterację 1 z 42 Story Points. Gdy liczby Stories nie pasują dokładnie, zawsze lepiej jest zostać trochę poniżej niż się przeciążyć. Trolle mogłyby zatem zdecydować o wejściu w pierwszą iterację z 39 SP.

Co dzieje się z biegiem czasu ze znormalizowanymi Story Points?

W pierwszej iteracji po prostu zgadywaliśmy. Zgadywanie jest lepsze niż nic. A potem działa Inspect+Adapt. Może Trolle nauczyły się, że rozgryzają Backlog jak gorący nóż masło. Następnym razem wzięłyby oczywiście trochę więcej Story Points. Może Borsuki nauczyły się, że muszą dużo robić dla innych zespołów (np. transfer wiedzy). W przyszłości nie brałyby już tak wielu Story Points.

ART-Velocity mogłaby z biegiem czasu rozwijać się tak:

Jak widać w tym przykładzie, zespoły stosują indywidualne Inspect+Adapt i kontrolują własną Velocity. Product Manager regularnie otrzymuje informację zwrotną, by dostosowywać ogólne planowanie produktu i cele PI (a w razie potrzeby też cele Release).

Ponowne szacowanie wcześniej oszacowanych Backlog Items odpada. Gdy znane są nowe tematy, „Done" Stories mogą być używane jako punkt odniesienia do spójnego szacowania przyszłych Backlog Items względem istniejących i przeszłych itemów. Znika powiązanie z osobodniem.

Ostrożnie ze znormalizowanymi Story Points

Story Points to nie biznesowa metryka! Podobnie jak Velocity. Są upraszczającymi metrykami planowania, które minimalizują nakłady na planowanie, dając jednocześnie wystarczające przekonanie co do wykonalności.

Te metryki podlegają w ART tym samym ograniczeniom co w Single-Team Scrum. Należy unikać następujących antywzorców.

W żadnym wypadku nie wolno:

• Traktować szacowań jako „poprawnych". Są – i pozostają – szacowaniami.

• Mierzyć postępu przez „dostarczone Story Points". Użyteczne produkty są podstawową metryką postępu!

• Porównywać zespołów na podstawie ich Velocity. Velocity to nie metryka wydajności!

• Optymalizować struktury ART pod kątem wartości Velocity. ART to wysoce złożony system adaptacyjny!

• Próbować utrzymywać Velocity na stałym/rosnącym poziomie. Planowanie pojemności to minimalizacja ryzyka. Jest ono podporządkowane rzeczywistości. Velocity to jedynie wskaźnik zwiększający niezawodność planowania!

Kiedy stosować znormalizowane Story Points?

Normalizacja Story Points rozwiązuje problem, który bez skalowania w ogóle nie istnieje. Odpowiada na pytanie: „Co się dzieje, gdy inne zespoły pracują nad tą historią?" Do tego rozumienie Story Point musi być jednolite ponad granicami zespołów.

Dzięki temu Backlog Items w ART mogą być stosunkowo łatwo przesuwane między zespołami, by zamiast obciążenia poszczególnych zespołów maksymalizować całkowitą wartość dostarczonego produktu.

Do czasu, gdy dostępne są lepsze informacje, przy bardzo prostym punkcie odniesienia i szacowaniu relatywnym można stworzyć dobry ogląd sytuacji. Z ukończonych Stories można wtedy wybierać „odpowiednio oszacowane", łatwe do zapamiętania Stories jako punkt odniesienia na przyszłość. Ponownych szacowań nie ma. Początkowo prosto przyjęte powiązanie między Story Points a osobodniami znika w bardzo krótkim czasie. To musi się stać, by Story Points pozostały spójne ponad zespołami.

Również dla wstępnego planowania Velocity używamy w braku lepszych informacji bardzo prostej zasady kciuka „80 procent dostępnego czasu". Gdy tylko pierwsza iteracja zostanie ukończona, używamy rzeczywistego wyniku jako punktu odniesienia na przyszłość i adaptujemy się. W ciągu kilku iteracji zanika też korelacja Velocity z czasową pojemnością. To też musi się stać, by Velocity jako narzędzie planowania mogło być stosowane w ART w sposób spójny i sensowny.

W ART jeszcze trudniej niż w Single-team Scrum jest oprzeć się pokusie oceniania zespołów na podstawie Velocity. RTE ma ważne zadanie: zapewnienie integralności Story Points przez blokowanie wszelkich prób (zazwyczaj ze strony zarządzania), które nadużywałyby Story Points lub Velocity.