W pierwszej części cyklu opisałem najczęstsze problemy z pielęgnacją Backlogu Produktu, z jakimi się zetknąłem. Części druga oraz trzecia zawierają omówienie błędów nieco mniej typowych. Pora przedstawić ostatnią porcję sposobów na to, by pielęgnacja stała się narzędziem destrukcji.

Sposób 14: dekompozycja po to, by „precyzyjnie” szacować

Wspominałem w poprzednim artykule cyklu o pochopnej dekompozycji elementów Backlogu, które niepotrzebne są dzielone na wiele części na długo przed tym, nim nastąpi realizacja któregokolwiek z takich małych kawałków. Są Zespoły, które nie dość, że robią to zdecydowanie za wcześnie, to jeszcze ze złego powodu: po to, by uzyskać małe elementy, które w ich opinii da się dzięki temu „precyzyjnie” wycenić.

Ta precyzja jest całkowicie pozorna. Dekompozycja dużego elementu na kilka mniejszych pozwala co najwyżej lepiej zrozumieć całość, o ile nie są tworzone przy okazji założenia, które weryfikowane będą dopiero w przyszłości. Zmienność i nieprzewidywalność pozostanie nieuchronnie na tym samym poziomie co przed podziałem. Dlatego mimo poczucia, że wyceny poszczególnych małych elementów są precyzyjne, z racji tego, że jest ich wiele, suma wszystkich małych błędów szacowania wciąż jest znacząca.

Na to nakłada się jeszcze ryzyko, że strategia podziału dużego problemu na kilka mniejszych jest nietrafiona. Skoro Zespół nie potrafi wyszacować całości z pożądaną precyzją, równie trudno będzie mu ustrzec się popełnienia błędów w trakcie dekompozycji, a te skutkować mogą w przyszłości problemami z ukończeniem prac.

Dzielenie elementów na potrzeby „precyzyjnego” szacowania to przepis na katastrofę. Dochodzi do dramatycznego spuchnięcia Backlogu Produktu (rośnie liczba elementów) i tym samym spadku jego przejrzystości. Mnóstwo pracy poświęcane jest na dekompozycję i szacowanie czegoś, co ma spore szanse nigdy nie być realizowane. Nieuchronnie podejmuje się wiele decyzji, które oparte są na założeniach i przewidywaniach. W tym i takich, które narzucą sposób realizacji poszczególnych elementów i tworzą niepotrzebne ograniczenia.

Osobną kwestią jest to, czy w ogóle da się uzyskać precyzyjne oszacowania. Moim zdaniem nie, dlatego piszę o „precyzji” dla podkreślenia, że jest ona zawsze pozorna. Otaczający nas świat dynamicznie się zmienia, często w zaskakujący sposób. Do tego ludzie marnie radzą sobie z analizą złożonych problemów i przy podejmowaniu decyzji zawsze wprowadzają upraszczające założenia, często nie zdając sobie z tego nawet sprawy. Dzieje się to zarówno w procesie szacowania, jak i w trakcie dekompozycji. Jakim cudem więc mogłaby ona sprzyjać podniesieniu precyzji przy szacowaniu?

Rozsądne Zespoły dążyć powinny raczej do wystarczająco precyzyjnych oszacowań, czyli takich, które pozwalają z akceptowalnym poziomem ryzyka podejmować różne decyzje. Jeśli element Backlogu Produktu jest wciąż daleki od realizacji, niech pozostanie w jednym kawałku ze zgrubnym oszacowaniem, które wskazuje, że konieczna będzie jego dekompozycja. Gdy przyjdzie na nią czas, najlepiej wydzielić na początek to, co powinno być zrobione najpierw, resztę pozostawiając w całości tak długo, jak to możliwe.

Ten wydzielony mały kawałek będzie dostatecznie dobrze zdefiniowany, by dało się go dość precyzyjnie wyszacować (o ile wycena będzie w ogóle do czegoś potrzebna). Zostanie też zrealizowany na tyle szybko, by poczynione wcześniej ustalenia nie zdezaktualizowały się całkowicie. A po zakończeniu prac nad nim, można użyć pozyskanej w międzyczasie wiedzy do podjęcia decyzji o dalszych losach tego, co pozostało w jednym kawałku.

Zdarza się, że od Zespołu precyzyjnych oszacowań domagają się kierownicy lub interesariusze, a czasami źródłem presji jest Product Owner, bo jest bardzo bezwzględnie rozliczany z wykonywanej pracy i nie może sobie pozwolić na żaden błąd w prognozach. Odradzam kontestowanie potrzeb, które nakłaniają ludzi do takich żądań – to zwykle nic nie da, a może spowodować dramatyczne pogorszenie sytuacji. Zamiast tego trzeba dążyć do zrozumienia, co jest przyczyną nierozsądnych żądań, a potem wypracowania lepszego sposobu zaspokojenia ujawnionych potrzeb.

Sposób 15: niewłaściwe użycie metody #NoEstimates

Do gwałtownego rozrośnięcia się Backlogu Produktu doprowadzają też Zespoły, które niewprawnie korzystają z techniki #NoEstimates. Wystarczy, że zainspirują się podpowiedziami osób utrzymujących, że wystarczy podzielić wszystko, co jest do zrobienia, na „kawałki równej wielkości”, a wtedy szacowanie staje się zbędne. Niepotrzebne mają stać się zatem same wyceny, stąd i nazwa techniki.

Oczywiście to bzdura: ustalanie, czy „kawałki są równej wielkości”, wymaga oszacowania ich wielkości. Najwyraźniej mechanizmem pozwalającym uniknąć szacowania ma być szacowanie…

W rzeczywistości #NoEstimates to technika szacowania, które polega na przypisaniu elementów do jednej z trzech kategorii:

  • rzeczy dostatecznie małych, by dało się je zrealizować bez dzielenia na części i zarazem dostatecznie zrozumiałych, by możliwe było zaplanowanie tej realizacji,
  • rzeczy zbyt dużych, które trzeba podzielić na kawałki przed realizacją,
  • rzeczy, których rozmiaru nie da się określić, bo są zbyt niejasne – przed umieszczeniem ich w jednej z pozostałych kategorii konieczne jest pozyskanie dodatkowej wiedzy.

Te bardzo proste kategorie zastępują typowe skale numeryczne lub symboliczne, jakie wykorzystują inne techniki szacowania. Dla większości Zespołów okazuje się to wystarczające, a jest zarazem łatwe w zastosowaniu.

Jeśli chodzi o nazwę, to rzeczywiście ma ona przypominać, że szacowanym elementom nie przypisuje się żadnych wycen, a jedynie jedną z kategorii. Przy czym te estymaty nie są zbędne ze względu na brak szacowania, ale po prostu nie istnieją ze względu na użycie sposobu szacowania, który jest ich pozbawiony.

Koniecznie muszę też wyjaśnić, o co chodzi z tymi „kawałkami równej wielkości”, bo nie jest to pomysł całkowicie wyssany z palca. Wiąże się z dwoma typowymi podejściami do określania, co może znaleźć się w pierwszej kategorii rzeczy dostatecznie małych i zrozumiałych. Te podejścia to same-sizing oraz right-sizing.

Same-sizing polega na dążeniu do realizowania rzeczy o wielkości takiej, pod której kątem został zoptymalizowany proces Zespołu i w związku z tym każde istotne odstępstwo od niej może być problematyczne. Inaczej mówiąc, rzeczy zbyt duże mogą zadławić Zespół całkowicie, a zbyt małych nie opłaca się realizować indywidualnie, tylko powinny być łączone z kilkoma innymi w większy pakiet.

Uwaga: same-sizing, którego echem zapewne jest to dążenie do tworzenia „kawałków równej wielkości”, nie wymaga uzyskania dokładnie takiego samego rozmiaru elementów, bo to byłoby skrajnie niepraktyczne. Chodzi o dążenie, by większość realizowanych rzeczy miała taką wielkość, z jaką Zespół radzi sobie najlepiej.

Right-sizing optymalną wielkość rzeczy definiuje nieco inaczej: nie muszą być do siebie zbliżone, ale nie mogą być zbyt duże. Chodzi o to, by chronić proces przed zablokowaniem jakimś jednym ogromnym elementem. Wszystko, co jest dostatecznie małe w ocenie Zespołu, ma właściwy rozmiar – stąd nazwa tego podejścia.

Sprawdza się ono dobrze np. w Zespołach Scrum, które podejmują do realizacji w Sprintach różnej wielkości elementy Backlogu Produktu, ale nie próbują ich łączyć w paczki standardowej wielkości na siłę. Ważne, by praca nad nimi kończona była w ramach jednej iteracji.

Technika #NoEstimates zastosowana z sensem jest mało czasochłonna i prosta, aczkolwiek nie wszędzie będzie efektywna. Czasami Product Owner musi dokonywać bardzo ostrej selekcji, co warto robić, a co usunięte zostanie z Backlogu Produktu i wtedy bardziej różnorodna skala wycen może okazać się niezbędna.

Sposób 16: nadmierne skupienie na narzędziach

W tym cyklu artykułów nie mogę nie wspomnieć o kolejnym błędzie popełnianym w ramach pielęgnacji Backlogu Produktu, czyli nieefektywnym użyciu narzędzi elektronicznych. Może objawiać się to na wiele sposobów – te typowe opisałem poniżej.

Pierwszym jest zastąpienie rozmowy komunikacją poprzez narzędzia. Ktoś spisuje wymaganie (najczęściej Product Owner, czasami ktoś inny na jego prośbę), po czym odbywa się wymiana komentarzy i uwag w narzędziu, ale nie ma dyskusji bezpośredniej. Ponieważ taki mechanizm wymiany informacji jest podatny na błędy interpretacji, na wszelki wypadek wszyscy starają się pisać dużo i „precyzyjnie”, żeby „wszystko było jasne”.

Efektem nie jest zwykle wzrost przejrzystości informacji, ale jej dramatyczny spadek. Kilkadziesiąt komentarzy i długi na parę stron opis daje poczucie, że niczego nie pominięto. Potem, w czasie realizacji wymagania okazuje się, że w komentarzach kilka razy zadano to samo pytanie, na które nikt nie odpowiedział, a wiele wpisów wyklucza się wzajemnie. Czemu nikt tego wcześniej nie wychwycił? Cóż, bo… było tego za dużo, więc nikt nie czytał całości.

Innym objawem problemu jest dokumentowanie bardzo szczegółowo wszystkiego, w tym przebiegu dyskusji, a nie tylko poczynionych ustaleń. Ktoś, kto chce zrozumieć, co właściwie uzgodniono, musi się potem przebijać przez rozbudowane zapisy, próbując odgadnąć, co z nich wynika na chwilę obecną. Pół biedy, jeśli się w tym nie pogubi. Gorzej, jeśli zostanie wprowadzony w błąd, który wyłapany zostanie nie w trakcie pielęgnacji Backlogu Produktu czy w ostateczności podczas Planowania Sprintu, ale już po rozpoczęciu developmentu albo wręcz po zakończeniu prac.

Kolejnym objawem nadmiernego przywiązania do narzędzia jest użycie go do sformalizowania procesu. Narzędzia kuszą możliwością definiowania list kontrolnych, szablonów na różne rzeczy, wiele z nich opiera się o mniej lub bardziej rozbudowane zarządzanie przepływem pracy (ang. workflow). Łatwo dojść do punktu, w którym Zespół, zamiast skupiać się merytorycznie na dyskusji i zrozumieniu potrzeb interesariuszy, zaspokaja wymogi narzędzia. Inaczej mówiąc, nie myśli o tym, co zapisać, ale jak powinno to być zapisane.

Bywa, że narzędzia wymuszają na Zespole określony sposób pracy z Backlogiem Produktu. Czasami to organizacja próbuje za ich pomocą doprowadzić do unifikacji procesów w różnych Zespołach, co może nie być dobrym pomysłem, ale czasami jest uzasadnione. Dostosowanie narzędzia do potrzeb Zespołu może wtedy wymagać zgody kierownictwa i musi zostać przeprowadzone przez uprawnionego administratora, dlatego następuje dopiero w ostateczności (jeśli w ogóle).

Zdarza się jednak i tak, że Zespół sam wybrał narzędzie i nim zarządza swobodnie, ale przez lata wytworzył tak skomplikowany zestaw reguł obowiązujących w procesie, że zmiany stają się ciężkie do zaimplementowania, więc z nich rezygnuje.

Jest i inny sposób, w jaki narzędzia potrafią szkodzić. Przyjmijmy, że Zespół nie komunikuje się poprzez narzędzia, tylko organizuje spotkania i dyskusja odbywa się bezpośrednio. Przyjmijmy też, że narzędzie nie ma jakichś ograniczeń ani nie wymusza na Zespole działania w określony sposób. Może się zdarzyć, że i tak stłamsi dynamikę spotkania, jeśli Zespół będzie próbował używać go do dokumentowania wszystkiego na bieżąco w czasie pielęgnacji.

Jak takie wygaszanie dynamiki wygląda w praktyce? Gdy tylko coś zostanie ustalone w trakcie dyskusji, ktoś rzuca się do klawiatury i tworzy notatkę. Pozostali czekają, aż skończy, często patrząc na pojawiający się na ekranie tekst. Piszący czuje presję, więc się spieszy. Pośpiech powoduje, że piszący popełnia błędy, ktoś zaczyna przypominać, że trzeba poprawić literówkę, stres powoduje kolejne błędy… Z efektywnej dyskusji Zespół nieuchronnie przechodzi do oczekiwania, aż jej efekty wtłoczone zostaną w narzędzie.

Może też zdarzyć się, że Zespół zacznie się spierać o to, w jaki sposób zapisać poczynione ustalenia w narzędziu. Dyskusja może być całkiem gorąca, ale obniża efektywność pielęgnacji, bo czas płynie nieubłaganie naprzód i lepiej byłoby wykorzystać go na omówienie większej liczby elementów Backlogu Produktu.

Jak uniknąć takich problemów? Niech ktoś na kartce czy w jakiejkolwiek innej formie robi notatki, może nawet mogą to robić dwie osoby. Na koniec wystarczy ustalić, kto przeniesie notatki do narzędzia już po spotkaniu. Okazjonalnie, wyłącznie kluczowe rzeczy, zapisane zostaną w nim na bieżąco. Dzięki temu sesja pielęgnacji zachowa dynamikę przez cały czas jej trwania, a ustalenia nie umkną.

Jeśli pojawią się obawy, że wyznaczony sekretarz coś pominie, wystarczy umówić się na sprawdzenie zapisków przez kogoś innego i ich ewentualne uzupełnienie. Przyjmując, że sesje pielęgnacji nie są długie (czyli że Zespół nie robi jednej długiej sesji na Sprint), ryzyko permanentnego zapomnienia o istotnych ustaleniach jest zerowe.

Sposób 17: pielęgnacja tylko na początku Planowania Sprintu

Pisałem wcześniej o Zespołach, które w czasie pielęgnacji Backlogu Produktu zaczynają w praktyce planować kolejne Sprinty. Zdarza się też coś dokładnie odwrotnego: Zespół nie przeprowadza żadnej pielęgnacji, a o elementach Backlogu Produktu dyskutuje po raz pierwszy dopiero w czasie Planowania.

Definicja Scruma nie zawiera wymogu organizowania pielęgnacji, więc formalnie to dopuszczalne. Co więcej, w rzadkich sytuacjach może mieć sens – jeśli Scrum użyty jest w środowisku bardzo uporządkowanym i przewidywalnym, albo jeśli Sprinty są ekstremalnie krótkie (np. dwu- lub trzydniowe). W większości przypadków pielęgnacja jest jednak niezbędna.

Pierwszy powód: Planowanie Sprintu musi trwać długo, bo sporo czasu potrzeba będzie na omówienie Backlogu Produktu. Do tego Zespół może w jego trakcie odkryć, że brakuje mu istotnych informacji niezbędnych do zaplanowania realizacji jakiegoś elementu. Wciąż może podjąć się prac nad nim, ale będą one obłożona sporym ryzykiem niepowodzenia – które być może dałoby się zredukować (albo wyeliminować), gdyby dzień lub dwa przed Planowaniem Sprintu odbyła się pielęgnacja.

Drugi powód: pielęgnacja odbywająca się na początku Planowania Sprintu skupiać się będzie w zasadzie tylko na elementach na szczycie Backlogu Produktu, bo nie będzie czasu rozmawiać o rzeczach, które na pewno w bieżącym Sprincie realizowane nie będą. Bardzo ciężko wtedy z wyprzedzeniem identyfikować zależności (bo w zasadzie tylko Product Owner będzie analizował całość Backlogu).

Powód trzeci: nagminne stanie się realizowanie dużych zmian w produkcie bez ich dekompozycji, czyli raz-a-dobrze, zamiast rozwoju inkrementalnego. Podział elementów Backlogu Produktu na mniejsze części wymaga bowiem czasu, pozyskania dodatkowej wiedzy, konsultacji z ekspertami, być może jakiegoś niewielkiego eksperymentu…

Sposób 18: Product Owner jedynym gospodarzem pielęgnacji

Co ciekawe, nawet jeśli pielęgnacje się odbywają, problem zbliżony do jej braku może wciąż wystąpić. Dzieje się tak wtedy, gdy pielęgnacja odpowiada wyłącznie na potrzeby Product Ownera i jest on jej jedynym gospodarzem. Uzyska od Developerów oszacowania, być może dostanie propozycje możliwych sposobów rozwiązania jakiegoś problemu, czy też listę zależności. Jeśli jednak Developerzy nie będą przekonani, że pielęgnacja jest też dla nich, i jeśli nie będą się czuli jej współgospodarzami – wtedy i tak na Planowaniu Sprintu będą pojawiać się kłopotliwe pytania.

Inaczej mówiąc, zdarza się, że źle organizowana pielęgnacja ma na celu tylko wsparcie Product Ownera w zarządzaniu Backlogiem Produktu, ale nie pomaga Developerom w przygotowaniu się do Planowania kolejnego Sprintu.

Sytuacja taka może być związana z nienajlepszymi relacjami w Zespole (np. Developerzy traktują Product Ownera jako klienta, który „zamawia” coś, co oni realizują). Może też wynikać po prostu z niezrozumienia celu pielęgnacji. A jest nim zarówno udoskonalenie Backlogu Produktu (ustalenie jego zawartości, kolejności, zapewnienie przejrzystości), jak i przygotowanie całego Zespołu do planowania kolejnej iteracji.

Pielęgnacja może być organizowana przez Developerów również bez udziału Product Ownera, jeśli uznają, że jej potrzebują np. po to, aby porozmawiać z ekspertem. Dzięki temu przy następnym spotkaniu z Product Ownerem będą mogli zaproponować możliwe warianty rozwiązania jakiejś problematycznej kwestii w produkcie. Przy czym ważne, by nie doszło do rozdzielenia pielęgnacji na dwa równoległe procesy: „pielęgnację biznesową” z Product Ownerem i „pielęgnację techniczną” w gronie Developerów, bo to doskonały generator chaosu (nie wszyscy wiedzą o podjętych kluczowych decyzjach, a poszczególne ustalenia są często niespójne).

Sposób 19: pielęgnacja poza Zespołem

Bywa też tak, że pielęgnacja odbywa się w ogóle bez Developerów. Product Owner, zamiast posiłkować się przede wszystkim Developerami, którzy budują produkt, rozmawia z zewnętrznymi ekspertami i na Planowanie Sprintu przynosi gotowe ustalenia. Nierzadko powstają wokół Product Ownera dedykowane grupy analityków i projektantów, które mają za zadanie go wspierać. W rzeczywistości to odtworzenie kaskadowego procesu znanego z metod projektowych, choć często opakowany jest on w pozory, które pozwalają utrzymywać, że to wciąż Scrum.

Nie ma niczego nagannego w tym, że Product Owner korzysta z pomocy ekspertów, dopóki nie redukuje to Developerów w Zespole Scrum do roli wykonawców prac zleconych. I nie chodzi tu tylko o dramatyczny spadek zaangażowania tak traktowanych Developerów w wykonywaną pracę. Zewnętrzna grupa ekspertów, działająca całkowicie w oderwaniu od bieżącego developmentu, podejmować będzie wiele decyzji przedwczesnych, opartych o błędne założenia. Dlaczego?

Przede wszystkim nikt lepiej niż Developerzy nie wie, jakie są ich możliwości. Po drugie, analitycy i eksperci niezaangażowani w development mają zawsze ograniczone zrozumienie bieżącego stanu tak produktu, jak i narzędzi wykorzystywanych przy jego rozwoju. Jeśli podejmują jakieś decyzje, które Product Owner ogłasza potem w Zespole, to z definicji muszą one być oparte na różnych założeniach i modelach, a te mogą rozmijać się ze stanem faktycznym.

Poza tym taki schemat współpracy w Zespole będzie powodował oddalanie się Developerów od Product Ownera. Coraz bardziej będzie on dla nich klientem, coraz mniej partnerem. To może spowodować, że niekoniecznie Developerzy powiedzą mu o wszystkich problemach, na jakie natrafiają w trakcie pracy z produktem, zwłaszcza jeśli związane to będzie np. z brakiem kompetencji lub błędem, jaki popełnili.

Ten spadek przejrzystości i zaufania może prowadzić do nieodwracalnych błędów decyzyjnych Product Ownera. Może też prowadzić do nieporozumień przy planowaniu pracy w Sprintach, a nawet błędnej interpretacji poszczególnych elementów Backlogu Produktu. Pojawić się wtedy może wzmożona kontrola ze strony Product Ownera, coraz większy formalizm komunikacji, coraz mniej elastyczny proces, coraz bardziej zachowawcze szacowanie i planowanie ze strony Developerów…

Dlatego, jeśli już korzysta się z ekspertów, którzy nie są częścią Zespołu, powinni oni brać udział w pielęgnacji również z Developerami, a nie tylko z samym Product Ownerem. Podobnie jak Product Owner powinien brać udział w dyskusjach Developerów np. z architektami i ekspertami technicznymi.

Sposób 20: bezrefleksyjne kopiowanie praktyk

Opisałem szereg dysfunkcji, które mogą pojawić się w procesie pielęgnacji Backlogu Produktu. Być może czytelnicy odkryją, że w jednym z punktów (a może wielu) opisałem sposób działania ich Zespołu. Czy to oznacza, że należy natychmiast wprowadzić zmiany? Oczywiście nie, bo moją intencją było opisanie zagrożeń i ewentualnych negatywnych konsekwencji, jakie ten czy inny sposób przeprowadzania pielęgnacji może przynieść. Każdy Zespół sam musi dokonać oceny, co w jego specyficznym kontekście jest korzystne, a co wymaga zmiany.

I tu dochodzimy do kolejnego z błędów, jakie popełniają Zespoły. Istnieje wiele poradników i wskazówek, jak pielęgnacja powinna być realizowana, ale nikt rozsądny nie zaproponował (i zapewne nigdy nie zaproponuje) uniwersalnego, jedynie słusznego sposobu, w jaki nad rozwojem Backlogu Produktu należy pracować. Niestety, nie oznacza to, że takich „uniwersalnych definicji” tego procesu nikt nie stworzył. Jest ich od groma, często wykluczają się wzajemnie, nierzadko ich twórcy są postrzegani jako autorytety – propagując, świadomie lub nie, złe praktyki.

Błędem Zespołu będzie użycie takiej gotowej instrukcji, bez upewnienia się, że ona w ogóle pasuje do tego, jak ten Zespół pracuje i jaki produkt buduje. Błędem też będzie uznanie, że raz-a-dobrze można taki proces pielęgnacji zdefiniować i od tego momentu kurczowo się go trzymać. Z upływem czasu zmieniają się potrzeby użytkowników produktu i interesariuszy, a za tym postępuje ewolucja zarówno Backlogu Produktu, jak i procesu jego pielęgnacji oraz samego Zespołu Scrum.

Błędem Zespołu będzie też rezygnowanie z praktyk tylko dlatego, że jakiś ekspert napisał lub powiedział, że mogą one być problematyczne. Niewykluczone, że ma rację, ale z różnych powodów wyjątkowo, w niektórych Zespołach, te „nienajlepsze” praktyki mogą być całkiem efektywne. Oczywiście sporo zależy od rodzaju problemu, o jakim mowa – bo, przykładowo, robienie kompletnych i bardzo szczegółowych analiz każdego wymagania z wyprzedzeniem wielu miesięcy nie będzie miało sensu niezależnie od sytuacji.

Podsumowując: nie jest złym pomysłem zainspirowanie się takim czy innym szablonem pielęgnacji, ale Zespół powinien mieć intencję wypracowania własnego procesu i jego świadomej ewolucji. Warto też znać słabości i ryzyka związane ze stosowanymi praktykami, ale niekoniecznie od razu trzeba z nich rezygnować, jeśli na razie nie potrafimy zastąpić ich czymkolwiek bardziej efektywnym.

Na zakończenie

Sporządzona przeze mnie lista błędów, jakie Zespoły popełniają w czasie pielęgnacji Backlogu Produktu, jest oczywiście niekompletna. Jest też subiektywna i nie każdy zgodzi się z moimi komentarzami. To naturalne i zrozumiałe. Mam wszakże nadzieję, że to, co napisałem, okaże się inspirujące. A także, że choć niektóre z moich wskazówek okażą się przydatne.