Angry cat

Dwadzieścia sposobów na zdemolowanie Backlogu Produktu, część 3

W pierwszej części artykułu opisałem najczęstsze problemy z Pielęgnacją Backlogu Produktu, z jakimi się zetknąłem. Druga część artykułu zawiera omówienie nieco mniej typowych błędów, jakie popełniają Zespoły. W tej części skupimy się na kolejnych pułapkach związanych z Pielęgnacją.

Problem #9: szacowanie do upadłego

Pozornie mało bolesnym, ale nagminnym błędem Zespołów w czasie Pielęgnacji Backlogu Produktu jest dążenie do tego, by wyszacować wszystkie wymagania. Czasami jest to wynikiem presji ze strony Product Ownera, czasami Scrum Mastera (który utrzymuje – błędnie – że wszystkie elementy Backlogu muszą być bezwzględnie wyszacowane).

Efektem takiego działania jest coś, co często nazywam „oszacowaniem zmęczeniowym” – w pewnym momencie Developerzy, którzy już mają serdecznie dość bezprzedmiotowej dyskusji, nie szukają już odpowiedzi na pytanie o wielkość wymagań (ich złożoność, pracochłonność, czasochłonność itd.), ale takiej wartości oszacowania, na które wszyscy są skłonni się zgodzić. I pojawiają się koszmarne pomysły w rodzaju wyciągania średnich z proponowanych estymat, dzielenia story pointów (jednostek niepodzielnych) na ułamki itd.

W efekcie Backlog Produktu co prawda jest w pełni wyszacowany, ale wartość (wiarygodność) estymat poszczególnych elementów jest znikoma. Co więcej, dyskusja nad oszacowaniami nie służy zrozumieniu tych elementów, ale szybkiemu uzyskaniu kompromisu. W niektórych przypadkach powoduje to systemowe zawyżanie estymat, gdy Developerzy są zachowawczy, bo są rozliczani z „niedowiezienia na czas” podjętych do realizacji wymagań. W innych przypadkach efektem jest zaniżenie oszacowań, gdy Developerzy nie starają się dostatecznie zrozumieć złożoności tego, co przyjdzie im zrealizować.

Po co w ogóle są oszacowania? By podjąć decyzję, czy warto coś robić, a jak już ją podejmiemy, by zdecydować, jak najsensowniej niezbędne prace wykonać. Oszacowania przypisane wymaganiom na odczepnego, bo „muszą być”, nie pozwolą skutecznie osiągać żadnego z tych celów. Są więc w istocie stratą czasu. Nie posłużą też do sporządzenia wiarygodnych prognoz odnośnie do tego, co i na kiedy może zostać zrealizowane w produkcie, bo będą obłożone sporym błędem.

Jeśli Zespół przestanie upierać się, że w ramach Pielęgnacji wszystko musi zostać wyszacowane – pojawią się nowe możliwości. Kiedy próba estymowania ujawni różnicę w rozumieniu wymagania, której nie da się zniwelować w krótkiej dyskusji, należy po prostu ustalić kto i co zrobi, by przed kolejnym podejściem (zapewne już na innym spotkaniu) dostarczyć Zespołowi więcej informacji. To oznaczać będzie, że często Pielęgnacja zakończy się nie tyle wyszacowaniem wymagań, ile wykreowaniem pytań, na które trzeba poszukać odpowiedzi – i dopiero po ich uzyskaniu będzie można pracę z tymi konkretnymi wymaganiami kontynuować.

Problem #10: Pielęgnacja tylko w czasie spotkania

I tu warto napisać o kolejnym typowym błędzie Zespołów, jakim jest organizacja Pielęgnacji jedynie w formie spotkań w czasie Sprintu. Pielęgnacja nie jest zdarzeniem zdefiniowanym w Scrumie, ponieważ jej forma, ilość i moment, w którym odbywać będą się spotkania (o ile w ogóle będą jakieś spotkania), zależy od specyfiki pracy Zespołu i produktu, jaki ten Zespół buduje. W praktyce Pielęgnacja wymaga spotkań (bo to przestrzeń do dyskusji), ale nie ogranicza się do nich – jest to bardziej proces, niż konkretne, punktowe zdarzenie.

Czas Developerów, Product Ownera i Scrum Mastera jest zbyt cenny, by tracić go na bezprzedmiotowe dyskusje, dlatego spotkania w ramach Pielęgnacji Backlogu Produktu powinny służyć do podejmowania decyzji (np. szacowania, dekompozycji wymagań), wymiany informacji (dyskusji), zadawania pytań.

Za każdym razem, gdy Zespół natrafia na niewiadomą, której nie da się wypełnić treścią w ramach spotkania – warto ustalić, co i kto przygotuje w związku z tym na kolejne spotkanie. W ten sposób Pielęgnacja będzie mieć formę krótkich zdarzeń, pomiędzy którymi Developerzy, Product Owner albo czasami Scrum Master, wykona jakąś niewielką pracę, której efekty pozwolą skutecznie działać w czasie kolejnych spotkań.

Problem #11: wielogodzinne sesje Pielęgnacji

Warto przy okazji uniknąć kolejnej pułapki. Wiele Zespołów „optymalizuje” Pielęgnację w ten sposób, że robi jedną długą sesję, w ramach której przygotowuje się do kolejnego Sprintu. Siłą rzeczy takie spotkanie bywa długie, nierzadko wielogodzinne. Niestety, jest też bardzo nieefektywne, z kilku powodów.

Po pierwsze, zdolność do zachowania koncentracji każdego z uczestników jest ograniczona i niekoniecznie taka sama. Część osób „odpada” dość szybko, inni trzymają się mocno, ale zasadniczo pod koniec każdy marzy jedynie o tym, żeby zakończyć spotkanie. To nie sprzyja merytorycznym dyskusjom, za to zachęca do podejmowania nieprzemyślanych decyzji.

Po drugie, taka jedna długa sesja może się nie odbyć, jeśli w Sprincie pojawi się coś niespodziewanego, wystąpi jakiś poważny problem. Zespół będzie miał wybór między zajęciem się tą palącą kwestią albo zrobieniem Pielęgnacji. Nawet jeśli się ona formalnie odbędzie, szanse na skupienie na Backlogu Produktu są nikłe, bo umysły Developerów zaaferowane będą bieżącym Sprintem. Efektem jest marne przygotowanie do Planowania Sprintu kolejnego.

Po trzecie, dość szybko w takich długich, jednorazowych Pielęgnacjach przestają uczestniczyć wszyscy Developerzy. Oczywiście nie jest wymagane, by zawsze wszyscy brali udział w Pielęgnacji (choć warto, by tak było), ale jeśli w Sprincie mamy tylko jedną sesję na to poświęconą, wysłanie kilku „delegatów” to zdecydowanie marny pomysł. A często tak się stanie, w szczególności, jeśli w Zespole mamy osoby specjalizujące się w sporządzaniu analiz. Pielęgnacja nierzadko zaczyna być spotkaniem Product Ownera z tymi osobami, pozostali Developerzy nie są zainteresowani. Stąd już krok do „ukaskadowienia” procesu i faktycznego (choć nieformalnego) podziału Zespołu na dwie części: analityczną i wytwórczą.

Po czwarte: jeśli będzie tylko jedna sesja Pielęgnacji, to kiedy ją zorganizować? Na początku Sprintu to mało sensowne, bo jeszcze za dużo się może zmienić. Na końcu też źle, bo już nie będzie czasu, by poradzić sobie z ewentualnymi problemami ujawnionymi w trakcie dyskusji. No, to może w połowie? Najczęściej tak właśnie się dzieje, tyle że to jednocześnie za wcześnie (bo wciąż dużo może się zmienić i unieważnić ustalenia poczynione w czasie Pielęgnacji) i za późno (bo może braknąć czasu na drugą, wcześniej nieplanowaną sesję, jeśli w Sprincie prace przebiegają niekoniecznie bezproblemowo).

I po piąte: taki model realizacji Pielęgnacji powoduje, że praktycznie odbywa się ona tylko na tym spotkaniu, ewentualnie niektórzy Developerzy zerkną być może do Backlogu Produktu dzień wcześniej. No, chyba że mamy w Zespole analityków – wtedy nierzadko ich praca w Sprincie zaczyna sprowadzać się do „robienia Pielęgnacji z Product Ownerem”, co już jest dalekim odejściem od idei Pielęgnacji w Scrumie.

Dlatego zamiast jednej sesji, Zespół powinien zaplanować kilka – krótkich, np. godzinnych, rozrzuconych na przestrzeni całego Sprintu. I użyć ich, jeśli będą potrzebne – albo odwołać, jeśli nie ma o czym dyskutować. To daje przestrzeń do dyskusji merytorycznej, a jeśli Zespół ugrzęźnie – nie musi kontynuować na siłę, tylko po prostu ustala, jak do kolejnej sesji dowiedzieć się więcej.

W ten sposób ten proces Pielęgnacji zyska też dodatkowy wymiar działań, które odbywać się będą pomiędzy sesjami. Nie mówiąc już o tym, że skupienie przez godzinę na Pielęgnacji jest o wiele prostsze niż w czasie spotkania trwającego trzy-cztery razy dłużej.

Problem #12: skupienie tylko na części Backlogu Produktu

Kolejnym częstym błędem Zespołów jest skupienie w ramach Pielęgnacji tylko na tym, co jest na szczycie Backlogu Produktu, a czasami wręcz na „najbliższym Sprincie” (choć przecież nie wiadomo, co tak naprawdę może się w Backlogu zmienić przed zakończeniem bieżącej iteracji).

Takie skupienie na wycinku Backlogu często wymusza formuła spotkania: jeśli jest to jedna długa sesja (o czym pisałem wcześniej), Zespół będzie dążył do tego, by jakoś ją ograniczyć. Jeśli do tego gospodarzem jest zawsze Product Owner, pojawi się pokusa myślenia przede wszystkim w kategoriach przygotowania do kolejnego Sprintu. O ile w założeniu to nie jest złe, o tyle nie wolno zapominać o zmienności Backlogu – i trzeba jednak poddawać go Pielęgnacji w całości.

Warto więc przyjąć taką zasadę, że w ramach Pielęgnacji omawia się nowe elementy – żeby potwierdzić, że są zrozumiałe, odpowiedzieć sobie na pytania, poprawić ich opis, wyszacować o ile okaże się to możliwe, zdekomponować, jeśli są za duże. Przy czym czynności te, związane z jednym wymaganiem, nie muszą odbyć się w ciągu jednej sesji. Właśnie dlatego lepiej jest tych sesji mieć kilka w Sprincie i w ramach każdej z nich zrobić jedynie część z tej pracy, rozkładając ją w czasie.

W efekcie cykl życia wymagania w Backlogu będzie np. taki: najpierw pojawi się ono w jakiejś formie, po dyskusji w czasie Pielęgnacji jakoś udoskonalonej. W kolejnej sesji zostanie wyszacowane, co ujawni, że wymaga podziału. Dekompozycja odbędzie się jeszcze na kolejnej sesji, przez co część oryginalnego wymagania powędruje na szczyt Backlogu, a reszta osunie się (jako mniej istotna) w dół. Kolejna Pielęgnacja zaowocuje wyszacowaniem tych przeniesionych w górę nowych elementów i dopisaniem do nich kryteriów akceptacyjnych, dzięki czemu Zespół uzna, że są na tyle małe i na tyle zrozumiałe, że da się zaplanować ich realizację w Sprincie.

Problem #13: dążenie do jednorodności oszacowań

Tu warto wrócić na moment do szacowania, o którym pisałem wcześniej. Presja na estymowanie z góry na dół wszystkich elementów Backlogu to nie jedyny problem związany z Pielęgnacją. Całkiem sporo Zespołów z uporem maniaka trzyma się jednej skali szacowania niezależnie od tego, jakie wymagania szacuje, co jest celem estymowania i w jakim miejscu Backlogu znajduje się dany element. A to błąd. Dlaczego?

Szacujemy z różnych powodów. Najpierw po to, by zgrubnie zrozumieć koszt dokonania zmiany i zderzyć go z oczekiwaną wartością (którą notabene też trzeba wcześniej oszacować). Na tym etapie nie potrzeba „precyzyjnych oszacowań”, często wystarczy rząd wielkości. Product Owner przed dodaniem wymagania do Backlogu potrzebuje najczęściej odpowiedzi, czy jest ono małe (do zrobienia w Sprincie), czy to raczej kolos na pół roku pracy ciągiem.

Jak już zapadnie decyzja (niekoniecznie ostateczna) o realizacji wymagania, szacowanie pozwala ujawnić różnicę w jego rozumieniu. Rozbieżność oszacowań nie jest zła – jest zaczynem dyskusji, której wynikiem jest lepsze zrozumienie problemu opisanego wymaganiem.

Jeśli oszacowanie ujawni, że wymaganie jest za duże do realizacji w całości, trzeba go podzielić – to kolejny powód, dla którego cokolwiek estymujemy. Dzięki podziałowi rośnie nasze zrozumienie wymagań, bo dekompozycja odkrywa często to, co wcześniej było niewidoczne (poza tym łatwiej zrozumieć rzeczy małe). Im mniejsze wymagania się stają, tym dokładniej da się je opisać i wyestymować.

Z tego wniosek, że tak naprawdę to, w jakich jednostkach, jaką techniką i w jakiej skali szacujemy, powinno być zmienne i zależeć od celu, dla którego sporządzamy estymatę. A także od momentu, kiedy to robimy.

Elementy na szczycie Backlogu Produktu będą małe, więc je pewnie szacować można technikami takimi jak Planning Poker, posługując się przy tym np. Story Pointami. Większe wymagania, które realizowane będą dopiero za jakiś czas, być może wystarczy wyszacować w rozmiarach koszulek. Pomysły biznesowe w dolnej części Backlogu wystarczy oszacować np. poprzez określenie przedziału Sprintów (albo tygodni, miesięcy czy nawet kwartałów), jakie może potrwać ich realizacja. W miarę, jak elementy będą się przesuwać w górę, ich oszacowania będą się zmieniać, bo dokonywana będzie dekompozycja, przedefiniowanie, doprecyzowywanie itd.

Czy da się przy pomocy tak niejednorodnych oszacowań stawiać jakiekolwiek prognozy w odpowiedzi na pytanie, kiedy poszczególne elementy Backlogu mogą potencjalnie zostać zrealizowane? Jasne, że tak.

Dla górnej części Backlogu będziemy mogli posłużyć się po prostu velocity albo przepustowością (ang. throughput) i ustalić, jak te małe wymagania rozłożyć się mogą w poszczególnych Sprintach (uwaga: to zawsze jest prognoza „na teraz”, bo Backlog może się przecież zmienić, podobnie jak tempo pracy Zespołu).

Jeśli środkowa część Backlogu wyszacowana została np. w rozmiarach koszulek, to Developerzy są bez wątpienia w stanie określić, jak te rozmiary mają się do standardowej długości Sprintu. I np. okaże się, że XXL to dwa do trzech Sprintów, XL to więcej niż Sprint, L to cały Sprint, M to około pół Sprintu pracy, S to praca na pół tygodnia, a XS to maksymalnie jeden dzień developmentu. Nie są to precyzyjne estymaty, ale da się to zgrabnie spiąć z prognozą granic Sprintów dla górnej części Backlogu.

A co z tymi ogromnymi wymaganiami na dole Backlogu? Jeśli są wyszacowane w przedziałach Sprintów (albo miesięcy, kwartałów) – da się to połączyć z prognozami uzyskanymi wcześniej. Oczywiście im dalej sięgamy w dół Backlogu, tym te prognozy będą mniej wiarygodne – ale to naturalne i nieuniknione. Gdybyśmy cały Backlog wyszacowali w Story Pointach za pomocą Planning Pokera, byłoby tak samo (a być może gorzej, bo zajęłoby to dużo czasu, nie dając w zamian nic, a wręcz prowokując do myślenia, że wiemy dokładnie, jak kosztowna jest realizacja całego Backlogu).

Na koniec uwaga: moja propozycja „mapowania” rozmiarów koszulek na przedziały czasu, w jakim wymaganie da się zrealizować, jest jedynie pospiesznie wymyślonym przykładem. Zwracam też uwagę, że jest to estymowanie czasu realizacji, choć wielu propagatorów metod zwinnych odsądza takie podejście od czci i wiary. Na swoją obronę przypominam, że w przykładzie posługuję się nie godzinami czy dniami roboczymi, ale raczej tygodniami i Sprintami. Co więcej, te zgrubne estymaty są zawsze określone jako przedział albo „prawdopodobne maksimum”, a nie konkretna, punktowa wartość.

To jeszcze nie koniec…

Zachęcam do lektury czwartej i zarazem ostatniej części artykułu, w której opisuję kolejnych kilka błędów związanych z procesem Pielęgnacji Backlogu Produktu.

Zdjęcie: Loan

Leave a Reply

%d bloggers like this: