Pracując jako Agile coach z Zespołami Scrum w różnych organizacjach, stosunkowo często zauważam w czasie Planowania Sprintu, że określenie jakiż to Cel Sprintu uda się osiągnąć poprzez realizację wybranych na ten Sprint wymagań bywa wyzwaniem. Przy czym problem nie jest natury lingwistycznej (jak ubrać Cel w słowa), ale dużo głębszej: to, co stanowi prognozę Zespołu na dany Sprint (ang. forecast), nijak nie daje się opisać skończoną ilością słów, a często i zdań.

Czy Cel Sprintu jest niezbędny?

Jedną z wartości Scrum jest skupienie (ang. focus). Dzięki skupieniu się na tym, co da się zrobić, ale też skupieniu na konkretnym celu, Zespół jest w stanie organizować swoją pracę w iteracji, efektywnie radzi sobie z utrudnieniami i poszukuje najlepszych rozwiązań. Sprzyja temu określenie mocnego Celu Sprintu: zrozumiałego dla wszystkich, dającego się dobrze określić, realnie osiągalnego i przede wszystkim wartego osiągnięcia.

Jednocześnie Cel Sprintu stanowi odpowiedź na pytanie o korzyść, jaką przyniesie wykonanie zaplanowanych prac itinerariuszom, czyli tym, na których rzecz Zespół Scrum pracuje. Brak odpowiedzi na to pytanie lub wręcz brak takiej korzyści, świadczyłby o marnowaniu czasu i skrajnie nieefektywnym postępowaniu Zespołu.

Cel Sprintu ma wszakże jeszcze inne funkcje, mniej oczywiste.

Przede wszystkim pozwala Zespołowi dokonywać świadomych wyborów w każdej sytuacji, gdzie nie jest oczywiste, które rozwiązanie lub droga będzie najlepsza. Jest to trudne, zwłaszcza jeśli porównujemy coś, co wydaje się mieć taką samą ilość zalet i wad. Jasny Cel, do którego realizacji dąży Zespół, pozwala wybrać takie rozwiązania, które sprzyjają osiągnięciu tego Celu. Czasami wymaga to zrobienia szybkiego eksperymentu, aby potwierdzić, czy warto iść jedną, czy drugą drogą. Zamiast grzęznąć w analizach i dyskusjach, Zespół świadomie spróbuje pójść przez chwilę każdą z dróg i po krótkim, ściśle określonym czasie ocenia, jak daleko dotarł każdą z nich. To ułatwi wybór i stanowi dobry przykład korzystania z empiryzmu.

Inna funkcja Celu Sprintu ujawnia się, gdy złożoność i nieprzewidywalność technologii, wymagań lub otoczenia spowoduje, że prace w Sprincie pójdą wolniej, niż Zespół zakładał w czasie Planowania. Można wtedy w kontekście Celu Sprintu zastanowić się, z czego zrezygnować, lub jak ograniczyć zakres prac, aby Cel nadal był osiągalny.

Cel Sprintu przydaje się także, gdy ze względu na wyjątkowe okoliczności Product Owner musi domagać się zmiany zakresu prac w Sprincie. Zdarza się to na przykład, kiedy dojdzie do jakiejś awarii lub ujawni się potrzeba dokonania pilnej zmiany niemogącej czekać na kolejny Sprint – powodów ku temu może być wiele. W istocie Scrum nie zakłada niezmienności wymagań i zakresu prac w trakcie Sprintu, bo to wymuszałoby rezygnację z pragmatyzmu – i tu pojawia się znów nasz Cel Sprintu. To ten Cel jest stały, a mając go, możemy podjąć decyzję, z czego w iteracji zrezygnować, by wciąż osiągalny był ten Cel, ale też by uzyskać czas niezbędny na poradzenie sobie z nieplanowanymi działaniami.

Kłopotliwy Cel

Określenie Celu Sprintu jest proste, jeśli Backlog Produktu uporządkowany został tak, że kolejne jego elementy opisują następujące po sobie etapy rozwoju produktu – na przykład od jego prostej, minimalistycznej wersji, przez wersje coraz bogatsze funkcjonalnie, do wszystko mającego ideału, którego zapewne nigdy nie uda się zrealizować. Backlog Produktu jest przecież opisem strategii rozwoju produktu, zdefiniowanej przez Product Ownera i powinien być układany z myślą o osiągnięciu jakiegoś wymiernego, dużego celu (Celu Produktu) – z którego powinny wynikać zatem Cele kolejnych Sprintów.

Dużo gorzej jest, gdy na szczycie Backlogu Produktu tkwią wymagania mało ze sobą powiązane, a w ekstremalnym przypadku opisujące zupełnie różne potrzeby biznesowe. W takim przypadku jednego celu działań w Sprincie nie ma w ogóle. I zaczynają się dziać dziwne rzeczy.

„Składak”

Typowy pomysł Zespołu w takim przypadku to „Cel składkowy”. Z listy wymagań, które będą realizowane w Sprincie, wybierane są te, które „stanowią Cel Sprintu” (cudzysłów nieprzypadkowy). Motywacja do osiągania takiego „Celu” nie bywa duża, bo w sumie nie jest on ani zrozumiały, ani przesadnie atrakcyjny. Ot, zróbmy, co do nas należy, żeby zrealizować taką czy inną arbitralnie wyznaczoną listę wymagań.

Wadą „składkowego Celu Sprintu” jest też to, że pojawia się pokusa jego osiągnięcia w sposób niekoniecznie wspierający empiryzm. Często bowiem jest tak, że taki „Cel” nie obejmuje wszystkich wymagań z prognozy na Sprint, ale tylko kilka z nich, czasami dosłownie dwa lub trzy z dziesięciu. Można zatem osiągnąć taki „Cel” bez realizacji dużej części (lub nawet większości) wymagań składających się na prognozę. Zdarzyło mi się zetknąć z procesową obsługą takiego „składkowego Celu Sprintu” przez podział wymagań w prognozie na te „gwarantowane – stanowiące Cel” i te „opcjonalne”, których… no właśnie, nie trzeba zrealizować? Dziwna sytuacja, jeśli o tym na trzeźwo pomyśleć.

„Składak” może też być dewastujący dla efektywności działania Zespołu i wartości, jaką Sprint przyniesie. Dlaczego? Bo najważniejsze dla Zespołu stanie się zrealizowanie wymagań, które objęte są takim „Celem Sprintu”. Jeśli okaże się, że wymagania sumujące się na ten „składkowy Cel” są bezsensowne i nie warto nad nimi pracować, najczęściej nie powstrzyma to Zespołu przed ich realizacją. Wszak stanowiły „Cel Sprintu”, który w Scrumie jest bardzo ważny. Pal licho, że nie o tak marny „Cel” w Scrumie chodzi…

A Celem niechaj będzie…

Innym pomysłem jest wskazanie jednego wymagania, które musi być zrealizowane na pewno i nazwanie go Celem Sprintu. Najczęściej jest to po prostu takie wymaganie, które w Backlogu Produktu znajdowało się na szczycie listy w momencie rozpoczęcia Planowania Sprintu. Jeśli takim Celem jest nazwane wymaganie, które znajdowało się nieco niżej, zapewne wszystkie wcześniejsze elementy stanowią dla niego zależność i wymagają realizacji, by taki Cel stał się osiągalny. W pewnym stopniu przypomina to wówczas „składaka” opisanego wcześniej, choć ma niewątpliwą przewagę nad nim: Cel taki jest bardziej konkretny, ma potencjalnie wymierną wartość dla interesariuszy, a reguły jego osiągnięcia jasne.

Problem z takim Celem w tym, że ciężko w jego kontekście decydować, co z zakresu usunąć albo jak zakres prac ograniczyć, jeśli zajdzie taka potrzeba. Wiadomo tylko, co trzeba zrobić na pewno, ale ciężko użyć Celu tego typu do podejmowania decyzji o innych wymaganiach realizowanych w Sprincie (no, chyba że stanowią one bezpośrednią zależność dla wymagania wyznaczonego jako Cel).

Pojawi się też pokusa, by zaangażować się wyłącznie w osiągnięcie Celu, a pozostałe wymagania, mimo że Zespół prognozował ich realizację w Sprincie, zepchnięte zostaną na dalszy plan. Z drugiej strony, jeśli Zespół jako Cel wyznaczy jedno wymaganie, do którego realizacji niezbędne jest ukończenie pracy nad wszystkimi pozostałymi, wtedy szanse na osiągnięcie tego Celu są nieprzesadnie wysokie, a sam Cel jest w praktyce niemożliwy do negocjacji i absolutnie nieelastyczny.

Formalnie też pojawia się i taki problem, że jeśli Celem będzie np. „funkcjonalność X”, to Cel ten stanowi odpowiedź na pytanie, co zostanie zrobione w Sprincie, a nie po co ta iteracja się odbywa. Wyobraźmy sobie, że na pytanie dziecka o to, dlaczego w gniazdku poza otworkami na wtyczkę jest metalowy bolec, padnie odpowiedź „to jest uziemienie”. Kompletnie nieprzydatna i niczego nie wyjaśniająca, czyż nie?

Cel: Cały Sprint!

A może, skoro już musiałby to być „składak”, to niech Celem Sprintu będzie zrobienie wszystkiego, co stanowi prognozę na Sprint? Jeśliby dobrze się zastanowić, ma to spory sens, ponieważ nie powstają wtedy domniemania, że coś może nie zostać zrealizowane. Nie ma też możliwości pójścia na skróty, by taki Cel osiągnąć (tu już cudzysłowu brak, bo też zrobienie wszystkiego, co zaplanowano w Sprincie, wydaje mi się sensownym Celem, przy założeniu, że wymagania z Backlogu Produktu faktycznie opisują coś wartościowego).

Oczywiście taki Cel wciąż jest „składakiem” z wieloma jego wadami: mało motywuje, nie daje też dużo elastyczności, gdyby trzeba było zmienić zakres prac w czasie trwania Sprintu. Można powiedzieć, że to najmarniejszy z możliwych sposobów ustalenia Celu Sprintu w Scrumie, który można zastosować, jeśli nie ma możliwości zrobić tego lepiej.

A może problemem nie jest Cel?

W istocie tym, co przyczynia się do kłopotów z nazwaniem Celu Sprintu, jest stan i zawartość Backlogu Produktu, w którym na początku listy mamy wymagania słabo lub wcale nieskorelowane ze sobą. Może to świadczyć o tym, że próbujemy zaspokajać potrzeby wielu różnych użytkowników lub interesariuszy równocześnie. Szeroką ławą idziemy w wielu kierunkach naraz. O ile bywa to niezbędne w skrajnych przypadkach, Product Owner powinien tego unikać. Nie dość, że komplikuje w ten sposób planowanie, utrudni pracę z Backlogiem i zmniejszy przejrzystość tego Backlogu, to jeszcze stępia lub całkowicie rozmywa cel, do którego realizacji zmierza rozwój produktu (Cel Produktu).

Brak możliwości zdefiniowania dobrych Celów Sprintu (wartościowych, zrozumiałych i negocjowalnych) bywa często pochodną braku wizji produktu. To ogranicza zaangażowanie wszystkich uczestników procesu, trudno też ocenić, co warto robić, a co można bez żalu usunąć z Backlogu.

Brak skupienia (znów nawiązuję tu do wartości Scrum) bardzo utrudni pracę zwinną jeszcze z jednego powodu: ponieważ próbujemy iść w kilka stron jednocześnie, w każdą z nich posuwać się będziemy bardzo wolno, wydłużać zaczynają się pętle feedbackowe i możemy przestać działać empirycznie. Pojawi się wtedy ochota na zaplanowanie wszystkiego przed podjęciem prac, a potem zrobienie wszystkiego raz a dobrze…

Jak temu zaradzić? Nawet mając wielu użytkowników lub wiele linii biznesowych korzystających z jednego produktu, należy mieć wizję rozwoju produktu jako całości. Na początek Product Owner powinien wyznaczyć pierwszy istotny cel biznesowy, do którego realizacji będzie dążył, a którego osiągnięcie przybliży produkt do zdefiniowanej wizji. Backlog Produktu powinien odzwierciedlać plan osiągnięcia takiego dużego celu biznesowego. Każdy kolejny Sprint powinien przybliżać Zespół do tego celu. Tym samym Cel Sprintu każdorazowo stanowił będzie odpowiedź na pytanie o to, jak prace, które wykonuje Zespół, pozwolą zbliżyć się do osiągnięcia przyjętego celu biznesowego. Gdy już się to uda, Product Owner wyznaczy kolejny istotny cel biznesowy, dostosuje do niego Backlog Produktu i cykl się powtórzy.

Taki sposób działania w Scrumie redukuje ryzyko pojawienia się „składaków” jako Cel Sprintu, wskazywania jako Cel konkretnych wymagań lub mówienia, że „Celem jest dostarczyć wszystko”. Nawet jeśli w niektórych Sprintach istotne będzie tylko jedno konkretne wymaganie, albo konieczne do osiągnięcia Celu okaże się zrealizowanie wszystkich wymagań, sam Cel będzie wynikał nie z tego, co podjęto do realizacji, ale z powodów, dla których Zespól podjął to do Sprintu. A powody te wynikać będą zarówno z wizji produktu, jak i celu biznesowego, który aktualnie wytycza kierunek rozwoju produktu.

Dzięki temu Product Owner będzie mógł wyjaśnić, dlaczego na szczycie Backlogu Produktu znajdują się takie, a nie inne elementy, a powód ten stanowić może idealny prototyp najbliższego Celu Sprintu. Oczywiście zdarzy się, że Zespół zdoła podjąć do realizacji mniej lub więcej, niż prognozował Product Owner, a wtedy niekoniecznie ów prototypowy Cel Sprintu zostanie wykorzystany. Niemniej jednak, zamiast skupiać się na tym, by przede wszystkim realizować wymagania, Zespół skupi się na tym, by przede wszystkim w każdym Sprincie przybliżyć się do znanego i wartościowego celu biznesowego.

Prawie zawsze spowoduje to, że co najmniej górna część Backlogu Produktu (o ile nie cały), zyska sporą spójność (funkcjonalną, biznesową, wydaniową, technologiczną itd.), czyli że elementy znajdujące się obok siebie będzie coś łączyć – wspólny powód, dla którego Product Owner ułożył je w taki właśnie sposób. To zdecydowanie ułatwi planowanie Sprintów, w tym ustalanie samego Celu Sprintu, a ten Cel również stanie się dzięki temu lepszy: bardziej zrozumiały, motywujący, jednocześnie elastyczny.

Może metoda jest nieodpowiednia?

A co robić, gdy zmiana Backlogu jest niemożliwa? Gdy musi w nim znajdować się „groch z kapustą”, czyli wymagania kompletnie ze sobą niepowiązane, choć pilne (każde z innego powodu)? Wciąż warto próbować ograniczać skalę problemu, dążąc do minimalizacji jednocześnie wyznaczanych celów, dzięki czemu może nie jeden, ale dwa biznesowe cele na Sprint uda się ustalić (zamiast dziesięciu) i ubrać w jakąś formę sensownego jednego Celu tego Sprintu.

Jeśli permanentnie jesteśmy skazani na „składaki” w jakiejkolwiek ich formie, warto zastanowić się, czy metoda wymagająca w swej istocie skupienia i możliwości określenia jasnych celów, jaką jest Scrum, jest rzeczywiście dobra dla nas. Może nasz Backlog nie opisuje zmian w produkcie niezbędnych do jego rozwoju, ale jest kolejką zleceń do wykonania w różnych jego obszarach? Może udajemy, że jednym produktem jest całe ich portfolio, ale pracy w każdym pojedynczym elemencie tego portfolio jest zbyt mało, by zajmował się nimi dedykowany Zespół? To tylko dwie możliwości wyjaśnienia przyczyn problemu, ale jest ich bez wątpienia więcej.

Gdy znajdziemy odpowiedź na pytanie, co zmusza nas do zajmowania się kompletnie różnymi rzeczami w jednym Sprincie, być może uznamy, że Scrum to nie jest najlepsza dla nas metoda i lepiej korzystać z innej metody, wspierając się w nim na przykład Kanbanem. Być może okryjemy, że mamy wiele produktów, a nie jeden; wtedy rozdzielimy ich Backlogi a Zespół – zamiast udawać, że pracuje ze wszystkimi na raz – będzie się przełączał między nimi co któryś Sprint? Może odkryjemy jeszcze coś innego?