W pierwszej części cyklu opisałem najczęstsze problemy z pielęgnacją Backlogu Produktu, z jakimi się zetknąłem. Druga część zawiera omówienie nieco mniej typowych błędów popełnianych przez Zespoły. W tej części skupię się na kolejnych sposobach na wywołanie katastrofy za pomocą pielęgnacji.

Sposób 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 jego elementy. Czasami jest to wynikiem presji ze strony Product Ownera, czasami inspiratorem jest Scrum Master, który utrzymuje – błędnie – że w Scrumie szacowanie jest obowiązkowe, a brak wycen obniża przejrzystość Backlogu. Rzadko na taki pomysł wpadają sami Developerzy.

Efektem skupienia pielęgnacji na wycenach jest uzyskanie czegoś, co często nazywam oszacowaniem zmęczeniowym – w pewnym momencie Developerzy, którzy mają serdecznie dość bezprzedmiotowej dyskusji, szukają desperacko takiej estymaty, którą wszyscy zaakceptują i będzie można się rozejść. Pojawiają się wtedy koszmarne pomysły w rodzaju wyciągania średnich z proponowanych wycen, dzielenia story pointów na ułamki itd. Z pozoru Backlog Produktu jest w całości wyszacowany, ale wiarygodność wycen poszczególnych elementów jest znikoma.

Czasami to szacowanie do upadłego wynika z potrzeby kierownictwa, które używa wycen do oceny efektywności pracy Developerów, Product Ownera i całego Zespołu. Wysokie oszacowania zwykle są przez nich interpretowane jako dowód na zbyt wolny i nieefektywny development produktu. Zbyt niskie, jeśli okażą się nadmiernie optymistyczne, skutkują pretensjami o „niedowiezienie tego, co miało być zrobione”. Proces szacowania staje się grą w dobieranie takich wycen, które są akceptowalne dla kierownictwa i zarazem bezpieczne dla Zespołu.

A tymczasem szacowanie powinno pomagać w lepszym zrozumieniu zawartości Backlogu Produktu, decydowaniu co warto robić, a co jest zbyt kosztowne, sporządzaniu prognoz i planowaniu developmentu. Wyceny ustalone na odczepnego nie pozwolą skutecznie osiągać żadnego z tych celów, mogą jedynie wprowadzać w błąd, bo zwykle skażone są ogromnym błędem szacowania.

Dojrzałe Zespoły nigdy nie ustalają „kompromisowych wycen” tylko po to, by uciąć dyskusję nad jakimś elementem Backlogu, ale też nie kontynuują jej po próżnicy. Jeśli ujawni się fundamentalna różnica zdań, uczestnicy pielęgnacji planują działania, które pozwolą uzyskać więcej danych do kolejnego spotkania.

Sposób 10: pielęgnacja tylko w czasie spotkania

I tu warto napisać o kolejnym błędzie Zespołów, jakim jest realizowanie pielęgnacji jedynie w formie spotkań. Pielęgnacja nie jest zdarzeniem zdefiniowanym w Scrumie, ponieważ jej forma, liczba spotkań i czas, w którym mają się one odbywać (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 bardziej proces, niż jego punktowe zdarzenie lub choćby ich seria.

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. o wycenach czy sposobie dekompozycji wymagań), wymiany informacji (dyskusji), zadawania pytań itd.

Natomiast 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 sesji, pomiędzy którymi Developerzy, Product Owner a czasami również Scrum Master, wykonają jakąś niewielką pracę, której efekty pozwolą skutecznie działać w czasie kolejnych spotkań.

Sposób 11: wielogodzinne sesje pielęgnacji

Warto przy okazji uniknąć kolejnej pułapki. Wiele Zespołów „optymalizuje” pielęgnację w ten sposób, że organizuje jedną długą sesję, w ramach której przygotowuje się do kolejnego Sprintu. Siłą rzeczy takie spotkanie bywa długie, nierzadko wielogodzinne i jest 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 wydarzy się coś niespodziewanego, czym trzeba zająć się pilnie. Nawet jeśli pielęgnacja się odbędzie, szanse na skupienie na Backlogu Produktu są nikłe, bo wszyscy zaaferowani będą przede wszystkim nowym problemem czekającym na rozwiązanie. Efekt: marne przygotowanie Zespołu do Planowania Sprintu.

Po trzecie, dość szybko w takich długich sesjach pielęgnacji przestają uczestniczyć niektórzy Developerzy. Oczywiście to normalne, że nie zawsze wszyscy będą brali w nich udział, ale rutynowe wysłanie kilku delegatów, żeby nie odrywać zbyt wielu ludzi od pracy to marny pomysł. Może spowodować podział na grupę zajmującą się bieżącym developmentem i drugą, skupioną na współpracy z Product Ownerem i przygotowywaniem Zespołu na przyszłe Sprinty. Stąd już krok do ukaskadowienia procesu, w którym wyłonią się wyraźne fazy: analityczna i wytwórcza.

Po czwarte: jeśli będzie tylko jedna sesja pielęgnacji, 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 trakcie pielęgnacji) i za późno (bo może braknąć czasu na drugą, wcześniej nieplanowaną sesję, jeśli okaże się ona jednak potrzebna).

I po piąte: taki model pielęgnacji jako jednej długiej sesji powoduje, że kojarzyć się ona zaczyna Developerom wyłącznie z tym spotkaniem. Mało który będzie regularnie zaglądał do Backlogu Produktu, by śledzić zmiany w nim. Być może zrobią to tuż przed sesją pielęgnacji, aby przygotować się do spotkania, choć wielu daruje sobie i to. Poziom znajomości Backlogu w Zespole zaczyna być mizerny, co znacząco utrudnia Planowanie Sprintu.

Dlatego zamiast jednej sesji, Zespół powinien ich zaplanować kilka – krótkich, np. godzinnych, rozrzuconych na przestrzeni całego Sprintu. I nie musi ich wszystkich wykorzystywać, jeśli nie będą potrzebne.

Krótkie sesje sprzyjają skupieniu na pielęgnacji, o co trudno w trakcie spotkania ciągnącego się godzinami. Jeśli sesji będzie kilka w każdym Sprincie, można pomiędzy nimi wykonać różne działania, by zebrać informacje potrzebne do merytorycznej dyskusji. Nie będzie też poczucia, że trzeba coś bezwzględnie ustalić w ramach jedynego takiego spotkania, skoro jest ich kilka, a jeśli to konieczne, można zorganizować dodatkowe.

Sposób 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 znajduje się na szczycie Backlogu Produktu.

Może wymusić to formuła pielęgnacji. Jeśli w Sprincie odbywa się tylko jedna sesja, Zespół będzie dążył do ograniczenia liczby omawianych elementów, żeby nie spędzić na pielęgnacji całego dnia. Co więcej, jeśli gospodarzem spotkania 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 musi być złe (bo taki jest zasadniczy cel pielęgnacji), o tyle nie wolno zapominać o zmienności Backlogu i trzeba jednak poddawać go pielęgnacji w całości.

Zwykle w ramach pielęgnacji omawia się nowe elementy Backlogu, żeby potwierdzić, że są zrozumiałe, postawić różne pytania i ewentualnie odpowiedzieć na nie, poprawić opisy elementów, dokonać ich wycen, być może zdekomponować je na mniejsze kawałki.

Natomiast dobrze zorganizowana i skuteczna pielęgnacja powinna obejmować również dyskusję o elementach dodanych do Backlogu Produktu niego wcześniej. Jeśli wymagają one wciąż doprecyzowania lub uaktualnienia, dobywać się to powinno na bieżąco w sposób regularny, a nie w trybie panicznym w ostatniej chwili przed Planowaniem Sprintu (albo wręcz w jego trakcie).

W praktyce pielęgnacja niemal każdego elementu Backlogu rozłoży się na kilka sesji, dlatego rozsądek podpowiada, by z góry zaplanować ich kilka w Sprincie.

Do tego warto w ramach każdej sesji pielęgnacji zawsze przejrzeć (choćby zgrubnie) całą zawartość Backlogu Produktu. Mogła się w nim zmienić kolejność elementów, ich opisy, a niektóre, choć wypielęgnowane wcześniej, mogą wymagać aktualizacji. Oczywiście, to może być trudne, jeśli Backlog Produktu jest rozległy, a staje się niemożliwe, gdy lista elementów jest zbyt duża, by dało się nią skutecznie zarządzać. Choćby z tego powodu wprowadzenie wspomnianej zasady jest pomocne, bo pojawienie się trudności z jej stosowaniem jest czytelnym sygnałem, że Backlog rozrósł się ponad miarę.

Sposób 13: dążenie do jednorodności oszacowań

Całkiem sporo Zespołów z uporem maniaka trzyma się jednej skali szacowania niezależnie od tego, co szacuje, do czego używać zamierza wycen i w jakim miejscu Backlogu znajduje się aktualnie dany element. A to błąd. Dlaczego?

Szacujemy z różnych powodów. Najpierw po to, by zgrubnie zrozumieć koszt dokonania zmiany w produkcie i zderzyć go z oczekiwaną wartością (którą notabene też trzeba wcześniej oszacować). Na tym etapie nie potrzeba „precyzyjnych oszacowań”, wystarczy określić rząd ich wielkości. Dobremu Product Owner na początek naprawdę wystarczy zwykle odpowiedź, czy jakaś zmiana w produkcie to coś małego (do zrobienia w Sprincie), czy to raczej kolos na pół roku pracy ciągiem.

Jak już zapadnie decyzja (niekoniecznie ostateczna) o dodaniu do Backlogu Produktu nowego elementu, szacowanie pozwala ujawnić różnicę w jego rozumieniu. Rozbieżność wycen nie jest zła – jest zaczynem dyskusji, której wynikiem jest lepsze zrozumienie opisanego problemu lub potrzeby użytkownika produktu.

Jeśli szacowanie ujawni, że element jest za duży do realizacji w całości, trzeba go podzielić. Dzięki podziałowi rośnie zrozumienie elementu Backlogu Produktu, bo dekompozycja odkrywa często to, co wcześniej było niewidoczne (poza tym łatwiej zrozumieć rzeczy małe). Im mniejsze te elementy się stają, tym dokładniej da się je opisać i wycenić.

Z tego wniosek, że to, w jakich jednostkach, jaką techniką i w jakiej skali szacujemy, powinno być zmienne i zależeć od celu, dla którego sporządzamy wycenę. 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. Te większe, które realizowane będą dopiero za jakiś czas, być może wystarczy wyszacować choćby w rozmiarach koszulek (małe, średnie, duże, bardzo duże itd.). Pomysły biznesowe w dolnej części Backlogu wystarczy oszacować np. poprzez określenie maksymalnej liczby Sprintów (albo tygodni, miesięcy czy nawet kwartałów), jakie są potrzebne na ich realizację. 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 wycen tworzyć jakiekolwiek prognozy w odpowiedzi na pytanie o daty realizacji poszczególnych elementów Backlogu? 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 realizacja elementów rozłożyć się może w poszczególnych Sprintach (uwaga: to zawsze jest prognoza na teraz, bo Backlog może się przecież zmienić, podobnie jak tempo pracy Zespołu). Możemy też sięgnąć po symulację Monte Carlo i na bazie przepustowości uzyskać nie jedną, ale całe spektrum prognoz wraz z oceną prawdopodobieństwa dla każdej z nich.

Jeśli środkowa część Backlogu wyszacowana została np. w rozmiarach koszulek, Developerzy są bez wątpienia w stanie określić, jak rozmiary mają się do standardowej długości Sprintu. I nie chodzi tu o przeliczenie symboli na dni robocze, ale określenie maksymalnego prognozowanego czasu realizacji.

Najlepiej pokazać to na przykładzie zaczerpniętym z pewnego znanego mi Zespołu. Otóż za bardzo małe rzeczy uznaje on to, co da się zrobić w ciągu jednego dnia (może to być równie dobrze pięć minut pracy, jak i kilka godzin). Małe elementy to takie, które wymagają kilku dni pracy, ale mogą zostać ukończone przez Zespół w ciągu tygodnia. Jeśli realizacja jakiejś zmiany w produkcie może potrwać więcej niż tydzień i ciągnąć się nawet przez cały Sprint, to znaczy, że opisujący ją element Backlogu ma średnią wielkość. Jest to zarazem sygnał, że może być konieczny jego podział na dwa mniejsze. Jeśli coś wymaga pracy Zespołu przez więcej niż jedną iterację, ale nie dłużej niż przez miesiąc, to jest to rzecz duża. A jeśli i miesiąca mało, to element jest bardzo duży.

Zwracam uwagę, że w opisanej skali konkretne kategorie wielkości szacowanych elementów wybierane są na podstawie oceny, jakiej pracy całego Zespołu mogą one wymagać. Nie są to precyzyjne wyceny, bo przedziały czasowe powiązane z poszczególnymi rozmiarami są szerokie – tym szersze, im większy jest rozmiar. Natomiast da się je bez trudu połączyć z prognozami odnośnie do tempa realizacji początkowej części Backlogu Produktu sporządzonymi z użyciem velocity albo przepustowości.

A co z tymi ogromnymi elementami na końcu listy? Jeśli są wyszacowane w liczbie Sprintów (albo miesięcy, kwartałów) również 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. Długoterminowe prognozowanie jest w istocie próbą przewidzenia odległej przyszłości i jest tym bardziej niepewne, im dalej sięgamy w przód.

Czy wyszacowanie całego Backlogu np. w story pointach za pomocą Planning Pokera pozwoli stworzyć odrobinę pewniejsze prognozy? Niestety nie, bo ich sprawdzalność nie wynika ze sposobu szacowania i formy wycen, ale z niestabilnej złożoności, z jaką się borykamy. Zespół uzyska więc co najwyżej takie same efekty, inwestując w to dużo czasu (bo Planning Poker jest techniką naprawdę powolną).

To wciąż nie koniec

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