Backlog Produktu a Planowanie Sprintu

Każdy, kto przeczyta Scrum Guide, dowie się, że Backlog Produktu to lista zmian, jakie Product Owner chce wprowadzić do produktu, aby możliwie szybko osiągnąć wyznaczony Celu Produktu. Zarówno ten Cel, jak i poszczególne elementy na liście definiuje Product Owner, bo wziął na siebie odpowiedzialność za rozwój produktu w sposób przynoszący interesariuszom maksymalne korzyści, jakie da się uzyskać racjonalnym kosztem.

Lista elementów jest uporządkowana w kolejności ich realizacji oczekiwanej przez Product Ownera, a zatem Backlog Produktu jest w istocie dynamicznie zmiennym i minimalistycznym planem osiągnięcia Celu Produktu.

Planowanie Sprintu polega na ustaleniu celu bieżącej iteracji i ustaleniu, które elementy Backlogu Produktu muszą zostać zrealizowane, by wspomniany wcześniej Cel Sprintu osiągnąć. Inaczej mówiąc, Zespół tworzy prognozę tego, co i w jaki sposób zrealizuje w Sprincie oraz jaką korzyść przyniesie to interesariuszom.

O tym, jak wiele elementów Backlogu Produktu podjętych zostanie do realizacji, decydują Developerzy, ponieważ to oni muszą dokonać niezbędnych zmian w produkcie zgodnie z wymogami jakościowymi zawartymi w Definicji Ukończenia. Product Owner i Scrum Master nie mogą wymusić na Developerach zgody na zaplanowanie wykonania prac, które w ich ocenie są niemożliwe do ukończenia w trakcie jednej iteracji. Natomiast cały Zespół wspólnie ustala, które elementy Backlogu Produktu będą realizowane.

Brzmi to wszystko dość prosto, ale wielu użytkowników Scruma dopowiada sobie do frameworku zasady, których Scrum Guide nie zawiera. Nie muszę chyba pisać, że te domniemane zasady nie wpływają korzystnie na sposób działania Zespołu. W tym artykule zajmę się czterema najczęściej obserwowanymi nieporozumieniami.

Elementy trzeba realizować po kolei… chyba że nie

Na początek trzeba rozprawić się z przekonaniem, że przy tworzeniu prognozy Sprintu Zespół musi bezwzględnie trzymać się ustalonej przez Product Ownera kolejności Backlogu Produktu. Czyli że żadne pomijanie elementów nie jest dopuszczalne.

To przekonanie ma silne podstawy: w końcu Product Owner określa kolejność realizacji elementów Backlogu Produktu i jej ignorowanie pozbawiałoby go władzy zarówno nad tym artefaktem, jak i w efekcie nad samym produktem. I z tym polemizować nie zamierzam.

Nie można jednak zapominać, że Backlog Produktu jest planem osiągnięcia Celu Produktu, a nie zleceniem wykonania przez Developerów określonych prac w konkretnej kolejności. Plany miewają do siebie to, że nie zawsze da się je wykonać zgodnie z założeniami, a czasami okazują się błędne.

W trakcie Planowania Sprintu Zespół może odkryć, że elementów nie da się zrealizować w zaproponowanej przez Product Ownera kolejności i niekoniecznie oznacza to, że pielęgnacja Backlogu Produktu była nieskuteczna. Do chwili rozpoczęcia Planowania Sprintu nikt nie jest w stanie na pewno powiedzieć, jaka będzie wtedy zawartość Backlogu Produktu, stan samego produktu oraz dostępność i możliwości Developerów. A ze zderzenia ze sobą tych trzech rzeczy wynikać może pojawienie się nieznanych wcześniej ograniczeń i zależności.

Mało tego: w trakcie Planowania Sprintu Zespół poszukuje najlepszego sposobu na wykorzystanie czasu, jakim dysponuje w iteracji, a nie wyłącznie skupia się na zaplanowaniu realizacji poczynionych wcześniej ustaleń. Czasami efektem dyskusji będzie odkrycie, że zamiast trzymać się kolejności elementów zaproponowanej przez Product Ownera, lepiej selektywnie wybrać kilka z nich, bo to pozwoli na osiągnięcie maksymalnej wartości.

A i to nie wszystko, bo przecież są też sytuacje, gdy pomysł, by zrobić coś w produkcie, pojawia się dopiero podczas Planowania Sprintu. Zespół może zaplanować jego realizację, mimo że stosowny element w ogóle wcześniej nie znajdował się w Backlogu Produktu, nie mówiąc już o tym, by znalazł się na początku listy.

Niezależnie więc od władzy Product Ownera nad Backlogiem Produktu i wyłączności do decydowania o nim, sam Backlog w trakcie Planowania Sprintu jest w istocie silną propozycją tego, nad czym i w jakiej Zespół może pracować w bieżącej iteracji. Propozycją, która może okazać się nie do końca trafiona i w uzgodnieniu z Product Ownerem Zespół nie będzie się jej trzymał.

Ktoś powie, że Product Owner w takiej sytuacji musi zmienić kolejność elementów, dzięki czemu ostatecznie Zespół wciąż będzie się jej trzymał bez żadnych odstępstw. Cóż, pewnie tak, ale zdecydowanie rozsądniej byłoby, gdyby Zespół skupił się na dyskusji o tym, co można zrobić w Sprincie, a nie nad tym, jak powinien być poukładany Backlog. Planowanie Sprintu służy temu pierwszemu celowi, nie ma więc sensu i wartości w zamienianiu go w sesję pielęgnacji Backlogu.

Nie warto tego robić również z innego powodu, o wiele istotniejszego. Otóż często okazuje się, że najlepszym, co Zespół może zrobić, jest odejście od zaproponowanej przez Product Ownera kolejności. A wiąże się to z kolejnym mitem, tym razem dotyczącym Celu Sprintu.

Cel Sprintu wynikać musi z prognozy… chyba że nie

Product Owner, gdy układa elementy na początku listy w Backlogu Produktu, powinien mieć jakiś zamysł, który z reguły stanowi niezły prototyp Celu Sprintu. Ten zamysł jest odzwierciedleniem strategii osiągania ustalonego Celu Produktu, jaką przyjął.

Czy Product Owner może obwieścić na początku Planowania Sprintu, co ma być Celem Sprintu, a następnie oczekiwać, że Zespół zaplanuje iterację w taki sposób, by go osiągnąć? Jasne, że nie, bo Cel Sprintu Zespół ustala wspólnie.

Kierując się tą zasadą i pamiętając o tym, że należy trzymać się kolejności elementów w Backlogu Produktu, wiele Zespołów najpierw ustala, jak wiele elementów – posuwając się w dół listy – może zostać zrealizowanych w iteracji. Po ustaleniu tej prognozy przechodzą do dyskusji o tym, co będzie Celem takiego Sprintu. A bywa to nietrywialne w sytuacji, gdy podjęte do realizacji elementy nie są ze sobą przesadnie spójne i ciężko objąć je wszystkie jednym hasłem, które nie będzie zupełnie pozbawione znaczenia.

Nic jednak nie stoi na przeszkodzie, by Cel Sprintu ustalić na początku Planowania, a dopiero kierując się nim, tworzyć prognozę tego, co zostanie w tej iteracji zrealizowane. Co więcej, Product Owner może, a nawet powinien ten swój prototypowy cel zaproponować – ważne, by go nie narzucał Zespołowi.

Kolejnym krokiem w tym modelu Planowania jest stworzenie prognozy, które elementy Backlogu Produktu pozwolą przyjęty Cel osiągnąć. Być może okaże się, że Product Owner całkiem trafnie ułożył elementy Backlogu Produktu i wystarczy trzymać się zaproponowanej przez niego kolejności. Częściej konieczne będzie pominięcie paru elementów, a być może stworzenie nowych, których potrzeba dodania do Backlogu ujawni się w wyniku dyskusji.

Może zdarzyć się, że przyjęty Cel Sprintu okaże się zbyt ambitny: pracy dla Developerów jest zbyt dużo, by dało się ją ukończyć w czasie jednej iteracji. Czy wtedy Zespół skazany jest na opisane wcześniej zgarnianie elementów z Backlogu Produktu po kolei i wymyślaniu, jaki Cel Sprintu z tego będzie wynikał? Absolutnie nie.

Zamiast tego, dopóki trwa Planowanie Sprintu, może sformułować propozycję innego, mniej pracochłonnego Celu Sprintu i powtórzyć proces dla niego. Za drugim razem już niemal na pewno nie uda się trzymać kolejności elementów Backlogu Produktu i Product Owner musi się z tym pogodzić. Nie ma też sensu, by na bieżąco próbował dokonywać zmian na liście, bo nie ma żadnej pewności, że ten drugi Cel Sprintu też nie okaże się nieosiągalny i trzeba będzie pomyśleć nad kolejnym, trzecim.

Efektem tego iteracyjnego i inkrementalnego Planowania będzie stworzenie prognozy, która jest realistyczna i w pełni skupiona na Celu Sprintu. Są dwa warunki, by to się udało: zaangażowany Zespół, który dobrze zna zawartość Backlogu Produktu i sam produkt oraz dobrze dobrany czas trwania Planowania Sprintu.

Czy to na pewno poprawne postępowanie w myśl definicji Scruma? Oczywiście, że tak, jeśli pamięta się, po co są w tej metodzie Sprinty. To nie kontenery na jakąkolwiek pracę związaną z realizacją zestawu elementów z Backlogu Produktu. Każdy Sprint powinien być wykorzystany do udoskonalenia produktu w taki sposób, by przyniosło to korzyści interesariuszom i by sam produkt przybliżył się do osiągnięcia określonego dla niego Celu Produktu.

To oznacza, że każde działanie Zespołu, które jest skupione na zaplanowaniu Sprintu w sposób pozwalający ten efekt osiągnąć, musi być prawidłowe w Scrumie. A każde, które popycha Zespół w inną stronę, może być niewłaściwe.

Planowanie Sprintów skupione przede wszystkim na tym, by zrealizować dużo elementów Backlogu Produktu, którego efektem jest Cel Sprintu niemający znaczenia (lub wręcz sprowadzający się do hasła „zrobić wszystko, co podjęliśmy do realizacji”), choć formalnie poprawne, zdecydowanie przyniesie interesariuszom mniej korzyści, a i na morale Zespołu może mieć dewastujący wpływ.

Cel Sprintu musi obejmować wszystko… chyba że nie

Skoro Cel Sprintu wyjaśnia, po co odbywa się Sprint, to wszystko, co Developerzy robią w Sprincie, powinno być z nim związane – to wydaje się oczywiste, ale często takie nie jest.

Zróbmy analizę konsekwencji przyjęcia, że wszystkie realizowane w Sprincie elementy Backlogu Produktu muszą być związane z Celem Sprintu. Jeśli Zespół już ustali, co jest potrzebne, by ten Cel osiągnąć, może odkryć, że pozostała przestrzeń do zrobienia czegoś jeszcze. Jak wtedy postąpić? Niepodjęcie kolejnego elementu do realizacji prowadzić będzie do zmarnowania istniejących możliwości. A żeby go podjąć, trzeba zmienić ustalony już Cel Sprintu i szukać nowego, na tyle pojemnego, by objął też tę dodatkową rzecz do zrobienia.

Brak elastyczności w podejściu do ustalania i użycia Celu Sprintu będzie popychał Zespół w stronę Planowania, w którym najpierw tworzona jest prognoza tego, co zostanie zrealizowane, a potem ustalany jest Cel Sprintu. Taki Cel zwykle jest słaby i nierzadko ustalany tylko po to, by formalnościom stało się zadość.

Przyjmijmy zatem, że Cel Sprintu nie musi obejmować wszystkich elementów Backlogu Produktu realizowanych w Sprincie i powtórzmy analizę konsekwencji. Zespół może ustalić jakiś sensowny Cel Sprintu i poszukać racjonalnego sposobu na jego osiągnięcie, a następnie ocenić, czy jest przestrzeń, by zrobić coś jeszcze. Jeśli tak, podejmie te dodatkowe elementy do realizacji w iteracji. A że nie będą one związane z Celem Sprintu, prace nad nimi rozpoczną się dopiero po tym, gdy Cel zostanie osiągnięty lub najwcześniej wtedy, gdy w ocenie Developerów nie będzie to zagrażać jego osiągnięciu.

Jak widać nadal wszystko, co Developerzy będą robić w trakcie Sprintu, podporządkowane będzie Celowi Sprintu, ale niekoniecznie wprost z nim związane. Co więcej, otwiera to przestrzeń do bardziej efektywnego Planowania Sprintów, o jakim pisałem wcześniej, czyli do wychodzenia od ustalenia naprawdę sensownych Celów i ustalania na ich podstawie, co powinno zostać zrobione.

W ekstremalnym przypadku może zdarzyć się, że dosłownie jeden element Backlogu Produktu jest związany z Celem Sprintu, a mimo to iteracja odbywa się właśnie po to, by go zrealizować. O ile nie dzieje się tak co Sprint, o tyle jest to dopuszczalne i zupełnie prawidłowe.

Gdy o tym mówię (np. na szkoleniach albo w dyskusji z różnymi Zespołami), spotykam się z wieloma obawami. Jedną z nich jest ta, że niezwiązane z Celem Sprintu rzeczy nie zostaną w ogóle zrobione, bo „nie będzie trzeba ich zrealizować, by osiągnąć Cel Sprintu”. Cóż, to prawda, można machnąć na nie ręką. Niemniej problem w Zespole, który tak postąpi, nie jest z Celem Sprintu i sposobem jego ustalania, ale z zaangażowaniem i profesjonalizmem Developerów. I wypadałoby rozwiązać go w inny sposób, niż wiążąc sznurkiem Cele Sprintów z listą realizowanych elementów po to, by wymusić zajęcie się nimi…

Inna obawa, jaką zgłaszają rozmówcy, jest związana z potencjalnym niedostatkiem czasu na zrealizowanie takich niepowiązanych z Celem Sprintu rzeczy. Jeśli miałyby zostać zrobione dopiero pod koniec iteracji, Developerzy mogą się nie wyrobić. Tak, to możliwe, ale chyba lepiej, żeby nie zostało zrobione coś, bez czego Cel Sprintu uda się osiągnąć, niż dążyć za wszelką cenę do wykonania wszystkich zaplanowanych prac, nawet jeśli może to spowodować, że Cel osiągnięty nie zostanie.

W istocie obawy te związane są zwykle z przekonaniem, że im wcześniej zacznie się dużo rzeczy robić naraz, tym większa jest szansa, że wszystkie zostaną ukończone na czas. W rzeczywistości jest zwykle odwrotnie – zachęcam do poczytania o prawie Little’a.

Kolejna obawa, a raczej obiekcja, z jaką się stykam: kto miałby powstrzymać Developera, który został przypisany do realizacji takiego niepowiązanego z Celem Sprintu elementu Backlogu Produktu przed zaczęciem prac od razu na początku iteracji? Pozostaje mi ciężko westchnąć, bo jeśli taki problem istnieje, to znów nie jest związany ze sposobem planowania i ustalania Celów Sprintu, tylko z organizacją pracy Zespołu. Rozdzielanie z góry już na Planowaniu Sprintu tematów między Developerów oznacza zwykle, że pracy zespołowej jest w iteracji bardzo niewiele (o ile w ogóle jakaś ma miejsce), a naraz robione jest tyle rzeczy, ilu Developerów liczy Zespół (tu znów kłania się prawo Little’a).

Reasumując: w dobrze zorganizowanym Zespole, w którym Developerzy dążą, by jak najlepiej wykorzystywać swoje możliwości i minimalizują liczbę rzeczy, nad jakimi pracują w sposób najbardziej zespołowy, żadne z podnoszonych problemów się nie materializują. A jednocześnie Zespół zyskuje sporą elastyczność odnośnie do sposobu ustalania Celów Sprintu, procesu planowania, jak i zarządzania pracą developerską, do tego maksymalizując wykorzystanie możliwości, jakimi dysponuje (ale bez nadmiernego ryzyka, że przeszarżuje).

Backlog Produktu to jedyne źródło pracy dla Zespołu… chyba że nie

Na koniec pora pochylić się nad kolejną typową nadinterpretacją zapisów z definicji Scruma. Tym razem chodzi o stwierdzenie, że Backlog Produktu jest jedynym źródłem pracy dla Zespołu Scrum.

Zdaniem wielu (dodam, że zaskakująco wielu) użytkowników Scruma, oznacza to, że nie wolno dokonać żadnej zmiany w produkcie, jeśli wcześniej stosowny element nie znalazł się w Backlogu Produktu, a następnie w ramach Planowania Sprintu nie został podjęty do realizacji.

A są tacy, którzy idą jeszcze dalej i utrzymują, że chodzi literalnie o każdą pracę, jaką wykonują Developerzy, Scrum Master i Product Owner, co ma prowadzić do konieczności umieszczania w Backlogu Produktu również zadań wykonywanych w ramach np. pielęgnacji Backlogu Produktu czy obsługi serwisowej użytkowników zgłaszających różne problemy z produktem.

Z wymogami Scruma ma to oczywiście niewiele wspólnego. Tak, Backlog Produktu jest jedynym źródłem pracy Zespołu, ale pracy rozumianej jako dokonywanie zmian cech funkcjonalnych i użytkowych produktu. Nie chodzi o literalnie każdą pracę wykonywaną przez ludzi w Zespole Scrum, ani nawet o każdą pracę nad produktem.

W szczególności po to, by naprawić błąd zgłoszony przez użytkownika, nie ma potrzeby uprzedniego umieszczenia opisu tego błędu w Backlogu Produktu. Usunięcie błędu skutkuje niewątpliwie jakąś zmianą cech użytkowych produktu lub jego funkcjonalności, ale stanowi przywrócenie do działania czegoś, co działało źle lub wcale. Inaczej mówiąc, nie jest to praca wykonywana w ramach rozwoju produktu, i o ile przynosi korzyść interesariuszom, o tyle jest w istocie spłatą zaciągniętego długu (spełnieniem obietnicy, która okazała się wcześniej niedotrzymana).

Również czysto technologiczne lub infrastrukturalne zmiany, jakie wprowadzane bywają do produktów, nie muszą być wcześniej opisane w Backlogu Produktu. Oczekiwaną jakość strukturalną rozwiązania określa Definicja Ukończenia i może zdarzyć się, że po dodaniu do niej nowych wymogów, które mają skutkować podniesieniem tej jakości, Developerzy wykonać muszą szereg prac nad produktem. Prace te można od biedy opisać w Backlogu Produktu, równie dobrze można je opisać od razu w Backlogu Sprintu, a czasami wystarczy samo zmodyfikowanie Definicji Ukończenia, by jasne stało się, co należy zrobić.

Na tym nie dość: jeśli Zespół w trakcie Sprintu odkryje, że aby osiągnąć ustalony Cel Sprintu, konieczne jest wprowadzenie do produktu zmian wcześniej nieplanowanych, powinien wykonać te prace – szczegóły ustalą Developerzy z Product Ownerem. Czy niezbędne jest dodanie stosownego elementu Backlogu Produktu, by potem z namaszczeniem wciągnąć go do realizacji w Sprincie? Nie, bo prawdopodobnie byłoby to tylko stratą czasu, który lepiej poświęcić na development.

Już słyszę okrzyki, że przecież to zaburzy wartość mierzonego velocity i mam od razu taką kontrowersyjną propozycję, by sięgnąć po inne miary, mniej podatne na zaburzenia, niż velocity (np. te związane z przepływem).

Będą też pewnie protesty, że działając w ten sposób – nie dodając nowego elementu nigdzie – tracimy kontrolę nad tym, co znajduje się w produkcie, przez co spada jego przejrzystość. Pozostaje mi ciężko westchnąć i przypomnieć, że o stanie produktu powinien zaświadczać jego sposób działania, dokumentacja i testy, jakie przeszedł, a nie lista elementów Backlogu Produktu, które ktoś tam zapisał w jakimś narzędziu elektronicznym i oznaczył jako zrealizowane. Zachęcam również przy tej okazji do poczytania, czym różni się zwinny rozwój produktu od realizacji klasycznych projektów.

Cały czas trzeba pamiętać, czym jest Backlog Produktu: to lista zmian, jakie Product Owner chce wprowadzić wraz ze swym Zespołem (albo Zespołami, bo może ich być wiele), by osiągnąć ustalony Cel Produktu. To informacja dla interesariuszy (np. użytkowników), co w produkcie zmieni się z ich punktu widzenia.

Natomiast nie jest to harmonogram prac dla Developerów, którzy po to, by utrzymywać produkt w należytym stanie technicznym, muszą wykonywać szereg prac, które nie są opisane w Backlogu Produktu, bo nie muszą być – wynikają albo z przebiegu Planowania Sprintu (i wtedy znajdą się w Backlogu Sprintu, jako cześć planu działania), albo z zapisów w Definicji Ukończenia i ustaleń poczynionych już na bieżąco w ramach developmentu.

Którego Backlogu użyć do czego?

Wspomniałem wcześniej o pomysłach, by w Backlogu Produktu opisywać wszystkie planowane prace, jakie wykonywać będą członkowie Zespołu Scrum – co byłoby nieporozumieniem. Backlog Produktu opisuje rozwój produktu, nie jest listą zadań czy harmonogramem prac dla Zespołu.

Dlatego też do tego Backlogu trafiać powinny rzeczy, które z różnych powodów Product Owner uzna za niezbędne do zrealizowania w produkcie, żeby dokonać jego dalszego rozwoju. Piszę o różnych powodach, bo w istocie są one dwa. Pierwszy: coś jest potrzebne, by osiągnąć Cel Produktu, a zatem praca nad tym czymś przybliży Zespół i sam produkt do tego Celu. Drugi: coś trzeba zrobić, bo jeśli nie zostanie zrobione, Cel Produktu będzie ciężko osiągnąć lub wręcz stanie się to niemożliwe. Do tej drugiej kategorii mogą trafić np. prace nad zaspokojeniem wymogów prawnych, które często utrudniają rozwój produktu, ale nie mogą być zignorowane, jeśli ma być możliwe jego legalne użytkowanie.

W Backlogu Produktu mogą zatem znaleźć się pomysły biznesowe, opisy problemów i potrzeb interesariuszy, a jeśli trzeba to także zgłoszenia błędów (jeśli nie są pilne i wymagają starannego wyboru momentu, gdy Zespół się nimi zajmie) oraz – jeśli to nieuniknione – opisy zadań, czyli konkretnych prac do wykonania w produkcie.

Nie powinny natomiast w Backlogu Produktu pojawiać się rzeczy niezwiązane z pracą nad produktem (to dość oczywiste), rozwojem samego Zespołu, narzędzi, jakimi się posługuje itd.

Niekoniecznie dobrym pomysłem jest umieszczanie w Backlogu Produktu opisu prac niezbędnych do usunięcia z produktu długu technicznego (czyli skutków niedoróbek i kiepskiej implementacji rozwiązań), bo nie dość, że zmusi to Product Ownera do zarządzania nimi (a niekoniecznie ma dość wiedzy technicznej, bo to zrobić), to jeszcze będzie miał pokusę, by odkładać to w czasie (przesuwając w dół listy), a wtedy produkt utonie w problemach…

Natomiast w Backlogu Sprintu, który powstaje w momencie Planowania Sprintu i ulega dalszym zmianom do momentu zakończenia iteracji, jak najbardziej znaleźć mogą się opisy prac technicznych, zadania do wykonania i cokolwiek, co Developerzy uznają za niezbędne. W tym opisy usprawnień i plan ich realizacji, pod warunkiem, że faktycznie Developerzy będą je wykonywać.

Bo nie wolno zapominać, że Backlog Sprintu jest artefaktem, którego używają Developerzy. Nie może więc Scrum Master lub Product Owner używać go do zapisu planów swojego działania i zarządzania nimi. Oznacza to, że jeśli Scrum Master chce dysponować jakąś wizualizacją na kształt Backlogu Sprintu, musi sobie stworzyć coś własnego. Nie ma takiego obowiązku, ale definicja Scruma tego nie zabrania. To samo dotyczy Product Ownera.

Przy czym Zespół może posłużyć się wspólnym artefaktem, jakim jest tablica kanbanowa, na której zwizualizowany będzie zarówno Backlog Sprintu, jak i prace Product Ownera i Scrum Matera. Kluczowe jest wtedy zadbanie, by jasne było, gdzie zaczyna się i kończy Backlog Sprintu na takiej tablicy, a co nie jest jego częścią. To już jednak temat na zupełnie osobny artykuł.