Porządny Backlog Produktu

Jak powinien wyglądać poprawny Backlog Produktu? Kogo warto zaangażować do tego? Do czego należy być przygotowanym? Mamy dla Ciebie sześć rad dzięki którym Twój Backlog Produktu będzie porządny. Dzięki nim będziesz wiedział/a na co zwrócić uwagę, a co jest mniej ważne.

Backlog Produktu odgrywa istotną rolę w realizacji celów, jakie stoją przed Zespołem Scrumowym, dlatego podzielimy się z Tobą 6 radami, które zebraliśmy podczas naszych doświadczeń w pracy w środowiskach zwinnych.

Zaczniemy najpierw od tego, czym Backlog Produktu jest, następnie powiemy m.in. o tym, jak się przygotować do jego tworzenia oraz czy warto eksperymentować z jego formą. Poruszymy też kwestię asertywności przy dodawaniu elementów do tej listy oraz jej regularnych przeglądach.

Czym jest Backlog Produktu?

Zgodnie z Przewodnikiem po Scrumie Backlog Produktu jest pewną uporządkowaną listą wszystkiego, co w danym konkretnym momencie wiemy o rozwoju produktu.

Za jej utrzymanie odpowiedzialny jest Product Owner. Od siebie dodamy, że istotne jest uporządkowanie tej listy wg priorytetów, jakimi będziemy się zajmować i po prostu musimy ustalić kolejność poszczególnych jej elementów. Nie ma tu miejsca na podział na must, should czy could, mamy się po prostu zdecydować, co będzie na pierwszym miejscu, co na drugim, a co na kolejnych. Oczywiście w trakcie pracy te rzeczy mogą zmieniać miejsca np. w związku z nowymi informacjami, które do nas napływają.

Istotne jest też, żeby treść w Backlogu niosła za sobą jakieś informacje, umożliwiając zespołowi rozpoczęcie pracy. Unikajmy ogólnych haseł, z których nic nie wynika. Jest to istotne, gdyż jest to jedyne źródło, z którego czerpiemy informacje, co jest do zrobienia i w jakiej kolejności. Dzięki temu nie ma zamieszania, bo rzeczy są rozproszone po kilku listach i nie wiadomo, czym się kierować.

Jak pracować z Backlogiem Produktu?

1. Zaangażuj Deweloperów w tworzenie Backlogu Produktu

W naszej pracy często spotykamy się z sytuacją, w której jedyną osobą, która dba o stworzenie i utrzymanie Backlogu Produktu, jest Product Owner. To niestety może prowadzić do sytuacji, że sporą część jego pracy pochłaniają właśnie te obowiązki. A to nie jest przecież jedyna jego rola, ma on więcej zadań, na które po prostu nie starcza mu czasu, np. na rozmowy z klientami.

Inną konsekwencją takiego stanu rzeczy jest pewnego rodzaju odcięcie zespołu od niezwykle istotnej wiedzy produktowej, co może pociągnąć za sobą brak zrozumienia, co jest do zrobienia. Ponadto Product Owner staje się wąskim gardłem w pracy z Backlogiem.

Aby uniknąć tych problemów, to warto zadbać o współpracę Deweloperów z Product Ownerem przy tworzeniu i zarządzaniu Backlogiem. Nie tylko Właściciel Produktu będzie odciążony, ale również deweloperzy będą mieli lepsze zrozumienie tego, nad czym pracują.

2. Bądź przygotowany na kolejny Sprint

Warto wiedzieć, czym będziemy się zajmować w najbliższym czasie obejmującym kolejny Sprint. Widzimy, że w zespołach, gdzie brak patrzenia poza obecny Sprint, planowanie kolejnych kroków, jest o wiele bardziej wymagającym zajęciem. Zaczyna się wymyślanie, kreowanie i rzeźbienie, co moglibyśmy zrobić.

Lepiej, jeśli to zadzieje się wcześniej, w procesie doskonalenia Backlogu Produktu. Świadomość tego, co będziemy realizować w kolejnym Sprincie, pozwala też szybko wyłapać ewentualne zależności zewnętrzne i odpowiednio wcześnie zapobiec opóźnieniom. Co więcej, te problemy lubią się potem przenosić na kolejne Sprinty, a w następstwie kumulować i prowadzić do chaosu.

Dlatego naprawdę warto poświęcić trochę czasu na Refinement, nawet kosztem realizacji zadań w danym Sprincie. Oczywiście  to nie gwarantuje sukcesu biznesowego tego, co robimy czy też 100% skuteczności, jednak niweluje przyczynę wielu problemów już u źródła.

3. Miej przygotowaną kolejną rzecz do zrobienia

Ta rada jest mocno powiązana z poprzednią, ale tu konkretnie wiemy, czym zajmiemy się w następnej kolejności. Mamy tu na myśli jakiś większy kawałek produktu czy większą funkcjonalność, którą możemy określić jako kolejny krok na road mapie.

Mimo że brzmi to bardzo oczywiście, to wciąż widzimy, że są zespoły, które nie mają takiego planu i nie są w stanie przewidzieć najbliższego większego kroku. Być może ten plan nawet jest, ale niestety tylko w głowie Product Ownera i interesariuszy.

Natomiast świadomość tego, w jakim kierunku idziemy, ułatwia podejmowanie decyzji w związku z tworzeniem produktu, jeśli zmieniają się plany biznesowe, jak i ma ogromny wpływ na motywację do pracy.

Co więcej, jesteśmy w stanie myśleć o kwestiach technologicznych bardziej przyszłościowo, wiemy, jak tworzyć obecne kawałki produktu, aby wspierały te, które dopiero powstaną w kolejnych Sprintach. Rzecz jasna, nie chodzi tu o posiadanie perspektywy rok do przodu, zaplanowanej i dobrze rozpisanej. Chodzi o tę kolejną, nadchodzącą rzecz.

4. Eksperymentuj z formą Backlogu Produktu

Eksperymentowanie może występować na bardzo wielu płaszczyznach. Przede wszystkim możemy eksperymentować z formą tego, jak Backlog Produktu jest przechowywany i prezentowany.

Przykładowo, jeśli na Przeglądzie Sprintu chcemy się podzielić z interesariuszami dalszymi planami produktowymi i je przedyskutować, to prezentacja tych planów w Jirze nie będzie najlepszym pomysłem. O wiele lepiej się sprawdzi, przygotowanie Backlogu np. w formie jakiegoś rzutu graficznego, osi czasu czy wizualizacji w Power Poincie. Innymi słowy, bierzmy pod uwagę kontekst, w którym jesteśmy i jaka forma prezentacji da najlepsze efekty, czyli zostanie zrozumiana przez odbiorców.

Podobnie, jeśli Backlog Produktu ma służyć zespołowi, to pytanie jest identyczne, czy faktycznie służy? Może jest tak, że Product Owner samodzielnie stworzył Backlog i udostępnił go tylko Deweloperom. Ci natomiast nie bardzo rozumieją kontekts i nie orientują się w nim. Stąd też drugie pytanie, jakie warto zadać, to czy możemy to jakoś zmienić?

To eksperymentowanie z Backlogiem opisujemy na przykładzie formy, jednak chcemy pokazać pewien sposób myślenia, jaki cały zespół może przeprowadzić. Co więcej, różne elementy Backlogu mogą mieć różne formy, w zależności czym są, komu będą prezentowane i w jaki sposób najlepiej je przedstawić. Być może warto zaprezentować coś w kontekście biznesowym, pokazać dodatkowe notatki lub kryteria akceptacji? A być może warto zrobić szkic rozwiązania lub makietę?

Pamiętaj też, że to są tylko nasze luźne pomysły, bez znajomości ani Twojego produktu, ani firmy. Wypracuj to wszystko wraz ze swoim zespołem i nasze propozycje traktuj tylko jako inspirację.

5. Okaż asertywność przy dodawaniu elementów do Backlogu Produktu

Przy tym punkcie nasuwa nam się historia z nagrania “Agile Product Owner Ship in a Nutshell” Henrika Kniberga. Definiując Backlog Produktu i rolę Product Ownera wspomniał on, że dodawanie elementów do Backlogu jest proste, o ile oczywiście nie jest to niekończąca się lista.

Natomiast o wiele trudniejsze dla Product Ownera jest odmawianie i niewpuszczanie pomysłów na tę listę czy też asertywne odrzucanie czegoś, po głębszym przemyśleniu. 

Zasadniczo, Backlog Produktu powinien wyrażać to, co wiemy i to, co chcielibyśmy mieć w naszym produkcie. Jeśli kontrolę nad wizją produktu oddamy całkowicie w ręce interesariuszy, to może stać się tak, że będziemy mieć niekończący się koncert życzeń.

Wizja produktu się rozmyje lub tak absurdalnie rozciągnie się w czasie, że nie będziemy mogli nawet oszacować, kiedy ten produkt będzie gotowy. Mamy świadomość, że nie jest to prosty temat i wiele zależy od pozycji Product Ownera w organizacji. Jednakże zalecamy w miarę możliwości dokładnie analizować, co wchodzi do Backlogu i nie doprowadzić do sytuacji, że będą tam trafiać wszystkie pomysły.

Jeśli interesariusze są nieugięci, warto spróbować wyjaśnić im jaką funkcję pełni Backlog Produktu, dlaczego nie chcemy tam wszystkiego dodawać i na czym skupiamy się w rozwoju produktu oraz jaka jest jego wizja.

Jeśli jesteś Product Ownerem, to warto się na chwilę zatrzymać przy tym punkcie i zadać sobie kilka pytań:

• Kiedy ostatni raz odrzuciłem/odrzuciłam elementy Backlogu?

• Jak często to robię?

• Jakie mam uprawnienia związane z decydowaniem, co się w Backlogu pojawi, a co nie?

Jeśli te uprawnienia są niewielkie, to wiele z naszych rad niestety traci sens. Być może potrzeba gruntownych zmian w kulturze czy strukturze organizacji, aby faktycznie móc prowadzić porządny Backlog Produktu.

6. Regularnie czyść Backlog Produktu

Oprócz tego, że powinniśmy ograniczyć to, co wchodzi do Backlogu produktu, to tak samo warto przeglądać go i pilnować czy, aby na pewno wszystkie elementy w nim zawarte są wciąż aktualne.

Może być tak, że coś było zgłoszone dawno temu i już nie ma sensu.

Może znajdują się tam jakieś duplikaty, bo dodając kolejny element, nie sprawdziliśmy, czy już nie istnieje w Backlogu. Często takie zbędne elementy zbierają się na dole listy, a my patrząc głównie na górę, zwyczajnie ich nie zauważamy.

W regularnym czyszczeniu Backlogu Produktu pomóc może ustawienie sobie przypomnienia, które z określoną częstotliwością będzie pojawiać się na naszym ekranie. Zadanie to może wykonywać Product Owner, Scrum Master lub oboje razem, jednak nie ma tu potrzeby angażowania całego zespołu. Jak często to robić? To zależy, jak dynamicznie zmienia się Twój Backlog i jak dużo rzeczy do niego wpada. Czasem wystarczy robić porządki co kwartał, a czasem warto częściej, np. co miesiąc.

Po co to robić? Jest pewien psychologiczny aspekt, który powoduje, że długie listy rzeczy do zrobienia zwyczajnie nas przytłaczają. Natomiast, jak się przypatrzymy dokładniej Backlogowi, to często się okazuje, że wiele rzeczy jest tam nieaktualnych, część już zrobiliśmy, część lepiej podzielić, a część się powtarza. Przez to ten metaforyczny słoń, który przed nami stoi, jest w istocie rzeczy o wiele mniejszy.

Mamy tu jeszcze taką wskazówkę, którą zapożyczamy od 37signals. W jednej z książek pisali o tym, żeby nie dodawać na listę rzeczy, które dopiero co przyszły od naszych klientów w formie pomysłu lub luźnej potrzeby. Jeśli są one naprawdę ważne, to wrócą one do nas ponownie, za jakiś czas. Być może jest to nieco skrajne podejście, ale w określonych warunkach może mieć sens.

Jak w Twoim zespole wygląda praca z Backlogiem Produktu? Kto się nim opiekuje? Eksperymentujecie z jego formą i dbacie o regularne przeglądy?

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Transkrypcja rozmowy „Porządny Backlog Produktu”

Kuba: W dzisiejszym odcinku poruszymy temat porządnego Backlogu Produktu. Zdefiniujemy ten temat, wyjaśnimy czym teoretycznie jest Backlog Produktu i w drugiej części odcinka przekażemy sześć podpowiedzi jak robić ten Backlog Produktu porządnie. Zacznijmy od definicji Jacek, jak definiuje Backlog Produktu Scrum Guide?

Jacek: Kiedy spojrzymy do Przewodnika po Scrumie no to dowiemy się, że Backlog Produktu to jest pewna uporządkowana lista wszystkiego, co w danym konkretnym momencie wiemy o rozwoju produktu. Scrum Guide zastrzega, że jest to jedyne źródło wiedzy na temat rzeczy, które chcemy w naszym produkcie wprowadzić. No i definiuje też właściciela produktu, czyli Product Ownera jako osobę, która jest odpowiedzialna za utrzymanie Backlogu, jego treść, dostępność i uporządkowanie elementów wewnątrz.

Kuba: Ja w tej definicji często osobom, które albo wyjaśniam Scruma, albo też trochę czasami koryguję jak jestem wezwany do jakiegoś zespołu, który boryka się z kłopotami. To zwracam uwagę na kilka takich akcentów, które w tej w sumie tej krótkiej definicji jest. Przede wszystkim Backlog to uporządkowana lista. Jeśli słuchaliście mojego live’a z Jackiem no to wiecie, że jestem trochę sceptyczny na temat metod typu Moscow, czyli jakichś takich metod, że coś jest priorytetowe, coś średnio, coś mało priorytetowe. Backlog Produktu idzie tutaj dosyć daleko i mówi – jest pierwsza rzecz, która jest na pierwszym miejscu, bo to jest uporządkowana lista. Jest druga rzecz, trzecia rzecz, czwarta rzecz. Po prostu trzeba się zdecydować jaka jest kolejność tego, co wiemy, że będziemy chcieli realizować w naszym produkcie i tylko jedna jedyna rzecz jest na pierwszym miejscu, a nie dwadzieścia procent, albo osiemdziesiąt procent must’ów czy jakieś inne takie reguły sztuczne i jednocześnie niepozwalające weryfikować. Co jeszcze byś wyakcentował z tej listy?

Jacek: Ja myślę, że pewne takie zadbanie o to, żeby ta treść w Backlogu, żeby ona niosła za sobą informacje. Czyli trochę więcej dzisiaj powiemy w dzisiejszym odcinku. Natomiast, żeby to nie były jakieś takie równoważniki zdania, jakieś takie ogólne hasła, z których niewiele wynika, tylko żeby jednak oczywiście w zależności od tego jak konkretny element jest blisko tego, że zostanie realizowany przez zespół. No to im bliżej tego, że będziemy się czymś zajmować, no to tym bardziej to powinno być przygotowane w taki sposób, żeby było to wystarczająco dobre informacyjnie dla zespołu, żeby mogli wystartować pracę z jakimś tam akceptowalnym ryzykiem, tę pracę wykonywać.

Kuba: No to tego, co powiedziałeś, jeszcze dorzuciłbym to, że Backlog to jest jedyne źródło zmian. Czyli jedyne źródło, z którego czerpiemy informacje, jedyne źródło, z którego czerpiemy tematy, które są do zrobienia. Co oznacza kilka możliwych kierunków. Przede wszystkim, nie istnieje żadna dodatkowa tajna lista. Nie istnieje jakiś Backlog techniczny. Nie istnieje Backlog błędów. Wszystko, co mamy do zrobienia jest w tym jednym miejscu. To stąd czerpiemy priorytety i kolejność. To stąd czerpiemy to co jest do zrobienia. No, a jeśli czegoś w Backlogu produktu nie ma, no to siłą rzeczy tego nie będziemy robić. I to czasami jest brutalne, czasami wymaga dodatkowych rozmów pomiędzy zespołem a Product Ownerem. Czasami pomiędzy Product Ownerem, a całą firmą. No ale tu właśnie tu takie narzędzie zostało wymyślone. W tym alternatywnym scenariuszu, w którym nie ma konkretnego jednego Backlogu Produktu odbywa się straszne zamieszanie. Nie wiadomo skąd czerpać te zadania, skąd czerpać priorytety. Jeśli nie tą listą, to inną listą może wepchnę zadania do jakiegoś konkretnego członka zespołu i się zaczyna robić chaos i zamieszanie.

Jacek: Chcielibyśmy właściwie w tym momencie tę definicję domknąć i skupić się na takich bardzo konkretnych sześciu podpowiedziach, jak dobrze pracować z Backlogiem Produktu. Pierwsza nasza podpowiedź brzmi: Zaangażuj Zespół Developerski w tworzenie Backlogu Produktu. Pracując z zespołami, pracując z firmami bardzo często doświadczam sytuacji, w której jedyną osobą odpowiedzialną za to, żeby ten Backlog Produktu stworzyć, utrzymać, uzupełniać, zarządzać nim jest Product Owner. To jest niestety w takim skrajnym przypadku często prowadzi do sytuacji, że sporą część czasu Product Owner poświęca na to, żeby ten Backlog podtrzymywać i żeby odzwierciedlać aktualną wiedzę o produkcie, na konkretnych elementach. No i niestety możemy się zgodzić, że ta postawa jest heroiczna, natomiast konsekwencji myślę jest parę. Pierwsza to jest to o czym powiedziałem, czyli jest co robić, więc de facto Product Owner być może spędzi więcej czasu produkując elementy Backlogu Produktu, zamiast spędzać ten czas na przykład z potencjalnymi klientami. Druga konsekwencja jest taka, że z mojej perspektywy jest to takie pewne odcięcie zespołu od tej wiedzy produktowej de facto, która jest niezwykle istotna. No żeby ten nasz produkt, jakikolwiek on jest – czy to jest produkt IT czy nie IT wyprodukować. Tak więc jakby co najmniej na tych dwóch płaszczyznach uważam, że sumarycznie zespół scrumowy traci, jeżeli Product Owner staje się takim wąskim gardłem i tylko on odpowiada za to, żeby na tym Backlogu Produktu pracować.

Kuba: Jakby używasz takich metafor typu wąskie gardło to ja bym dorzucił jeszcze tutaj metaforę głuchego telefonu. Czyli najpierw Product Owner dzielnie tworzy jakieś elementy Backlogu. Być może jest w tym wszystkim jakiś rozbudowany proces myślowy, przemyślenia, analizowanie, wymyślenie jakiegoś konkretnego rozwiązania po czym do zespołu dociera już na gotowo Backlog Produktu, czy jego elementy. Musimy sobie wyjaśnić, dlaczego takie, co jest w ich szczegółach. Być może pewne kontekstowe kawałki umykają. Zarówno gdy te elementy do zespołu docierają do zespołu, na początku pokazywane są przez Product Product Ownera, jak i potem w czasie developmentu będą się pojawiały pytania i ten czas pozornie zaoszczędzony, że Product Owner gdzieś tam w swoim zaciszu gabinetu sam zrobił te elementy, to tak naprawdę ten czas pozornie zaoszczędzony później będzie musiał być spłacony, bo albo development team nie będzie wszystkiego rozumiał i trzeba będzie to wyjaśniać, albo – co gorsza – nie będzie pytań, ale tak naprawdę zrozumienia też nie będzie. Kwitując tę myśl to zaangażowanie może pomóc z jednej strony odciążyć trochę Product Ownera z tej najbardziej tej przyziemnej pracy, a z drugiej pracy jest to jeden z dobrych sposobów na wspólne zrozumienie czym w ogóle się zajmujemy i czym jest ten nasz produkt i czym są te konkretne najbliższe kawałki, które w nim będziemy zmieniać.

Jacek: Drugą poradę, którą przygotowaliśmy: Bądź przygotowany na kolejny Sprint. Formułując tę poradę mamy na myśli taki horyzont raczej krótkoterminowy. Czyli chcemy dosyć precyzyjnie wiedzieć, tak dosyć dokładnie czym będziemy się zajmować w kolejnym Sprincie. Przez obserwację sytuacji, w których takie rzeczy się nie dzieją, zespół kończy przegląd Sprintu, jest jakaś informacja zwrotna od interesariuszy, podsumowujemy, w międzyczasie jest przeprowadzana retrospektywa i wchodzimy sobie w planowanie Sprintu. To jest taki ten moment, kiedy de facto zaczyna się rzeźbienie, wymyślanie, kreowanie co tam moglibyśmy zrobić, to zapiszmy, to przygotujmy. Wszystko to, co powinno się zadziać o wiele wcześniej w procesie doskonalenia Backlogu Produktu. Tak więc jeżeli chodzi o ten nadchodzący Sprint, no to z mojej perspektywy powinniśmy być dobrze przygotowani ze sporą jasnością na temat tego, co będziemy realizować, w jaki sposób, tak, żeby to nie było takie absolutne wejście we mgłę i dopiero wtedy w trakcie Sprintu eksplorujemy, dowiadujemy się, odkrywany na przykład, że mamy jakieś zależności zewnętrzne. Zwykle mówię, że to już jest za późno. Jakby ta detonacja problemów następuje w sprincie, gdzie moglibyśmy bezpiecznie sobie zdetonować wcześniej z wyprzedzeniem, tak żeby na skutek detonacji po wybuchu zobaczyć – dobra, ok, to tu musimy się dowiedzieć, tu musimy sprawdzić, tu musimy doprecyzować. Tak więc to przygotowanie na nadchodzący Sprint – z mojej perspektywy – znacznie obniża ryzyko wystąpienia problemów w trakcie Sprintu.

Kuba: To nieprzygotowanie czy też detonacje lubią się dziedziczyć między Sprintami. W jednym Sprincie nie byliśmy gotowi, kiepsko nam wyszło, więc zaczyna się robić lekka afera, więc znowu nie robimy zbyt dobrego Refinementu lub wcale go nie robimy. To niestety bardzo łatwo wpaść w taką śmiertelną pętlę, w której każdy kolejny Sprint jest coraz bardziej chaotyczny, czy coraz bardziej zbliża nas do kryzysu, więc coraz bardziej stresujemy się, że może się nie wyrabiamy i niestety już wpadamy w taki wir, z którego będzie bardzo trudno się wyrwać. Jak można się z niego wyrwać? Tu trzeba bardzo twardej decyzji zarówno zespołu, jak i Product Ownera, żeby autentycznie poświęcić ten czas na refinement. Być może poświecić jego więcej niż wszyscy mamy przeczucie, że go potrzebujemy. Bo jeśli jesteśmy nieprzygotowani na najbliższy Sprint to prawdopodobnie tego Refinementu robimy za mało, niż nam się wydaje, że jest wystarczająco. Faktycznie, jeśli to coś pomaga, to pomaga faktyczne poświęcenie dużego czasu, być może trochę przystopowanie developmentu w tym bieżącym Sprincie, żeby wyskoczyć na taką właśnie fajną krzywą wzrostową, w której każdy kolejny Sprint jest dobrze przemyślany. To nie gwarantuje jeszcze jego stuprocentowej skuteczności. To w szczególności nie gwarantuje sukcesu biznesowego, tego, co robimy. Przynajmniej na najbardziej przyziemną bolączkę możemy zastąpić, przynajmniej te Sprinty zaczynają się z myślą, że z grubsza wiemy co robimy, umiemy je zaplanować, umiemy je podzielić, umiemy też zaplanować te zależności, o których mówiłeś.

Jacek: Trzecią poradę, którą przygotowaliśmy: Miej przygotowaną kolejną rzecz do zrobienia. Tak jak w poprzednim punkcie mówiliśmy z Kubą o tym takim najbliższym horyzoncie, czyli dokładnie horyzoncie kolejnego Sprintu, tak tutaj świadomie chcieliśmy odejść od radzenia na ile Sprintów w przód być przygotowanym, no bo to jest bardzo relatywna informacja, stąd zgodziliśmy się, żeby mieć przygotowaną kolejną rzecz do zrobienia na zasadzie – jakiś taki większy kawałek produktu, czy jakąś większą funkcję produktu. Nazwaliśmy go sobie taki kolejny krok na road mapie. Jakby ktoś nas zapytał, jak skończycie, to co teraz robicie, to co będziecie robić, no to jest właśnie ta odpowiedź. To tak niekoniecznie jesteśmy w stanie dokładnie powiedzieć, kiedy i też często nie jesteśmy w stanie powiedzieć ile to nam zajmie, ale po tym, co robimy, kolejną rzeczą będzie coś. Pomimo iż to brzmi bardzo oczywiście, może przecież powinniśmy to wiedzieć, no to znów bardzo często doświadczam sytuacji, w której zespół nie ma takiego planu, nie jest w stanie przewidzieć ani najbliższego kroku, ani najbliższych dwóch, trzech czy pięciu. Co oczywiście może wskazywać na to, że być może nie ma jakiejś takiej road mapy, czy jakiegoś takiego planu w głowie Product Ownera. No stąd też takie narzucenie sobie rygoru, wiedzmy co będzie kolejne, pozwala ten problem zaadresować.

Kuba: Powiedziałeś, że nie ma planu. Czasami się spotykam z przypadkiem takim pomiędzy. Ten plan nie jest tylko w głowie, albo Product Ownera albo jakiegoś Product Ownera z grupą interesariuszy. Natomiast to de facto potem nic nie zmienia, bo jeśli zespół tego nie rozumie, jeśli pozostali interesariusze nie mają tej informacji no to gubimy parę elementów. Dlaczego zależało nam na tym punkcie, co będzie tym następnym fajnym krokiem? Kilka scenariuszy. Ten najbardziej pesymistyczny – jeśli to coś następne, co planujemy do zrobienia jednak z jakiegoś powodu jest niewskazane i na przykład to interesariusze dadzą nam znać, słuchajcie nie rozwijajmy produktu w tę stronę, bo my właśnie wielką strategiczną biznesową decyzją podjęliśmy decyzję o porzuceniu rynku niemieckiego. No, to jeśli porzucamy rynek niemiecki, no to może nie róbmy wersji niemieckiej. I ten cały wielki klocek z Backlogu Produktu w zasadzie bez większego przygotowywania już nawet, po prostu wyrzućmy i w niego nie inwestujmy więcej uwagi. Z drugiej strony już może bardziej optymistyczne, ja bym poszedł w tę stronę taką świadomości, w którą stronę zmierzamy. Zarówno motywacyjnej, czyli cały zespół wie, że jak już zrobimy to coś, co robimy to są kolejne rzeczy. Te kolejne rzeczy mają dla nas sens, my je rozumiemy. Chce nam się je robić. Rozumiemy jaki jest potencjalny wpływ biznesowy na to, na nasz produkt. A z drugiej strony też taka technologiczna perspektywa. Widzimy w którą stronę to mniej więcej ten nasz produkt idzie, więc też jesteśmy w stanie myśleć na tym takim strumieniu architektury, jakichś rozwiązań narzędziowych, rozwiązań może technologii, których używamy. Wiemy jak mniej więcej szykować się pod to coś, co będziemy realizować. Oczywiście tu można się zapędzić. Mówimy tutaj o przygotowaniu kolejnej rzeczy do zrobienia, a nie posiadania perspektywy roku w przód, precyzyjnej takiej, tu pięknie rozpisanej i zaplanowanej perspektywy. No to prawdopodobnie będzie waste. Ale czasami pod tym płaszczykiem waste’m czy marnotrawstwem będzie zaplanowanie za dużo rzeczy na przód. Niestety za często widujemy zespoły, które nie planują kompletnie nic na przód. Bardzo osłabiają swoją pozycję w różnych perspektywach, ale też między innymi osłabiają swoją wiarygodność jako zespół, który może realnie dostarczać wartość dla organizacji.

Jacek: Czwartą poradą, którą przygotowaliśmy dzisiaj, która brzmi: Eksperymentuj z formą Backlogu Produktu. Jest to dosyć szeroki punkt, ponieważ uważamy, że eksperymentowanie może występować na bardzo wielu płaszczyznach. To co mi w szczególności przychodzi do głowy, to forma tego, jak ten Backlog jest przechowywany i prezentowany. Tutaj taki przykład, którym chciałem się podzielić, jest sytuacja w której na przeglądzie Sprintu chcemy podzielić się z obecnymi interesariuszami dalszymi planami produktowymi, może też trochę podyskutować co dalej. Uważam, że w tym kontekście użycie przykładowo konkretnie Jiry, żeby wyświetlić te plany, nie jest najlepszym pomysłem. Z tego względu, że po prostu to narzędzie nie jest moim zdaniem do tego przygotowane. O wiele lepiej z mojej perspektywy działa, to kiedy my w jakieś innej atrakcyjnej formie przygotujemy Backlog Produktu, na przykład w formie jakiegoś takiego rzutu graficznego, czy takiego bardziej wizualnego pokazania na przykład w Power Poincie na jakiejś osi czasu, co mniej więcej mamy zaplanowane, jak ten nasz plan się układa. Tak więc raczej bym szukał sposobów, żeby przedstawiać tą treść, którą mamy w Backlogu Produktu w różny sposób, w zależności od konkretnej sytuacji. Żeby to nie była zawsze Jira, czy Trello, czy jakiekolwiek inne narzędzie tylko po prostu, żeby zastanowić się jak najlepiej możemy skorzystać z wiedzy, którą mamy w Backlogu i w jaki sposób tę wiedzę zaprezentować.

Kuba: I cała porada jest o eksperymentowaniu, ale na przykładzie tej formy pokażemy pewien sposób myślenia, który cały zespół może przeprowadzić, no najprawdopodobniej na retrospektywie. Po pierwsze zastanówmy się, czy to co robimy wnosi wartość tym naszym odbiorcom. Czyli jeśli chcemy Backlog Produktu pokazać interesariuszom, czy to jest czytelne dla nich? I to, że my się super wyznajemy w Jirze, jeśli w ogóle tak jest i tam wiemy, gdzie co kliknąć i na co patrzeć. To jeszcze nie oznacza, że jak interesariuszowi pokażemy cały ekran, na którym gdzieś w prawej kolumnie jest full informacji, w lewej jakieś nagłówki. Ja w ogóle nie wiem gdzie patrzeć na pierwszy rzut oka. Z tego powodu może nam się wydaje, że pokazaliśmy Backlog Produktu, a interesariusz przez pierwszą minutę wodził wzrokiem po ekranie i nawet nie wiedział co mu dokładnie pokazujemy i które punkty. Jeśli Backlog Produktu służyć ma nam jako zespołowi, to to pytanie jest identyczne. Czy faktycznie służy? Czy może ten, kto uzupełniał, że wrócimy tutaj do pierwszego punktu, na przykład Product Owner, sam to wszystko ogarnął i nam nagle na twarz rzucił trzydzieści elementów, to on wie doskonale – no zobacz, tu, przed ostatni, a my w ogóle nie wiemy gdzie jesteśmy. Więc czy służy ten Backlog Produktu tym odbiorcom do tego, do czego ma służyć? To jest jakby pierwsze pytanie. A drugie pytanie jakie sobie można zadać. Czy możemy to zmienić? Wiele zespołów może mieć taki nawyk czy takie przyzwyczajenie. No przecież już mamy. W naszej firmie Backlog trzyma się w Jirze. W naszej firmie Backlog ma formę User Stories. W naszej firmie Backlog jest rzucany w taki, a nie inny sposób w czasie spotkań zespołów. I to wszystko może powodować, że nawet nie dopuszczamy możliwości, że Backlog właśnie możemy przekopiować do innego narzędzia, przepisać na jakąś kartkę, wrzucić na jakiś share’owany plik. Może zrobić karteczki w Muralu, a może jeszcze totalnie zamanewrować i jeszcze inaczej to przebudować. Bo zazwyczaj wątpię, że firma dosłownie wymaga, żeby to tak dokładnie wyglądało. To często po prostu będą takie przyzwyczajenia czy nawyki. Tak po prostu zaczęliśmy, tak to robimy, ale nie musimy tak robić, zwłaszcza jeśli się okaże, że stare metody nam nie służą, a nowe coś tam poprawiają, coś tam zmieniają. Więc podsumowując, warto sobie zadać pytanie, czy nam to do czegoś służy, jak to możemy zmienić i czasami nie mamy jakichś nawyków, albo wyobrażeń, że nie da się tego zmienić, a zmienić się da. No i po prostu zróbmy eksperyment. Jeden Sprint często wystarczy, żeby spróbować. Możliwe, że ten eksperyment wcale nie da od razu gotowej recepty, ale rozrusza nas, żeby tutaj coś zmienić. Czy może podsuniesz coś jeszcze więcej?

Jacek: Właśnie chciałem dodać, bo tak rzuciłeś format User Story, jako też taki przykład. I to też bym pogłębił, na takiej zasadzie, że to też jest w wielu zespołach takie założenie, że to musi być każdy element Backlogu w formie User Story. Oczywiście to Scrum nie mówi nic o tym. To jest raczej praktyka pomocnicza, którą wiele zespołów scrumowych decyduje się wykorzystać. Tak więc sama ta forma jak zapisujemy elementy w Backlogu to też bym poddał pod eksperyment, na pewno czy potrzebujemy format User Story. Inna sprawa, co byśmy chcieli umieścić w takim nazwijmy to szablonie, naszego konkretnego elementu. Może jakiś kontekst biznesowy, może jakieś kryteria akceptacji. Jak te kryteria akceptacji byśmy chcieli zapisać, w jakiej formie. Czy może jakieś notatki, które wyłonią się w trakcie dyskusji? Czy może się umówimy, że zawsze potrzebujemy jakiś szkic rozwiązania? Albo jeśli rozwiązanie jest tam jakieś wizualne no to może jest to jakaś makieta, zakładając, że robimy takie rozwiązanie cyfrowe. Tak więc nie tylko jak przedstawiać Backlog jako całość, ale schodząc też trochę niżej zastanowiłbym się jaki sposób uchwycenia tej naszej wiedzy na temat produktu daje nam wartość. Wielokrotnie widziałem pojedynczy element Backlogu Produktu, który przewijało się przez trzy, cztery ekrany i to była po prostu ściana tekstu. Nikt nie zgłaszał ku temu obiekcji, do momentu, kiedy zapytałem, czy jest wartość z tego, że to jest tak zapisane. No oczywiście zespół się godził, że jak najbardziej nie i że to jest nieczytelne i czy musimy tak robić No i to jest właśnie taki przykład na to, że być może długa dyskusja, dlaczego zespół sam nie podjął dyskusji na ten temat. Natomiast domykając tę myśl to na pewno to eksperymentowanie też z tym jak zapisujemy rzeczy w Backlogu z tym takim mocnym akcentem, żeby to miało dla nas sens i wartość to jest inny przykład tego, co mam na myśli, kiedy myślę o tym, co to znaczy eksperymentować z Backlogiem Produktu.

Kuba: Ja dorzucę od razu zastrzeżenie, że zdążyliśmy już w tej krótkiej odpowiedzi dorzucić kilka konkretnych praktyk, które nam przychodzą do głowy jako warte spróbowania, ale częścią eksperymentowania jest również takie trochę kwestionowanie autorytetów. Czyli to, że Jacek wymienił na bezdechu, po przecinku takich elementów konwencji pisania Backlogu Produktu, to jeszcze nie znaczy, że trzeba od razu na taką najgłębszą możliwą wodę nurkować. Ja rekomenduję wypracuj sobie swoją własną konwencję. Wypracuj ją sobie w swoim zespole, ze swoim zespołem. Te przykłady, które wymieniliśmy w tym akurat punkcie traktuj raczej jako inspirację, jako możliwe poszerzenie kierunków czy horyzontów, a niekoniecznie Jacek powiedział do spóły z Kubą, że tak to trzeba robić. Od dzisiaj, od następnego Sprintu nasz Backlog Produktu będzie radykalnie lepszy. Radykalnie prawdopodobnie się utopisz w bagnie i może zespół nie być przekonany do tak radykalnego eksperymentu.  

Piątą naszą podpowiedzią jest podpowiedź o treści – Okaż asertywność przy dodawaniu elementów do Backlogu Produktu. Tutaj nasuwa mi się taka historia z filmiku Agile Product Owner Ship in a Nutshell – Henrika Kniberga, który definiując Backlog Produktu i definiując rolę Product Ownera używa takiego stwierdzenia, że dodawanie kawałków do Backlogu czy jakichś takich elementów czy zleceń czy zamówień jest proste, jeśli nie jest to niekończąca się lista. O wiele trudniejszą funkcją Product Ownera jest odmawianie, odrzucanie tych pomysłów czy w ogóle nie wpuszczanie ich na tę listę czy też jakieś asertywne odrzucanie po przemyśleniu. No i tutaj tę podpowiedź chcielibyśmy Ci przekazać, bo to jest i o Backlogu Produktu i trochę o roli Product Ownera, ale więcej o tym, dlaczego jest to dla nas ważne dopowie Jacek.

Jacek: Generalnie ten Backlog Produktu powinien wyrażać to co wiemy i to co byśmy chcieli mieć w naszym produkcie. Jeżeli tę naszą wizję produktu jako Product Owner oddamy kompletnie w ręce Stake Holder’ów i w takim skrajnym przypadku oni nas zdominują i rozpoczniemy taki niekończący się koncert życzeń. Może się okazać, że ta nasza wizja produktu absolutnie się rozmyje, albo tak szeroko rozciągnie się w czasie, że tak naprawdę trudno będzie powiedzieć, kiedy to będzie gotowe, kiedy nasz produkt ujrzy światło dzienne. Tak więc temat generalnie też nie jest prosty, bo dużo zależy od tego jak Product Owner pozycjonuje siebie w organizacji. Jak jest umocowany w strukturze, plus parę innych takich nazwałbym to systemowych czynników, które to definiują, Natomiast dążyłbym do sytuacji, w której mamy jakiegoś takiego po staropolsku powiem – Gate Keeper’a, czyli osobę, która jednak będzie stała na straży co do tego Backlogu Produktu wchodzi a co nie wchodzi. Jeżeli tam zaczniemy wrzucać wszystko no to raz, wszystko to co powiedzieliśmy, czyli bałagan, być może rozmycie wizji, ale z drugiej stronie wystawiamy się na dużą presję ze strony Stake Holder’ów. Jeżeli obiecaliśmy trzydziestu osobom, że coś dla nich zrealizujemy to te trzydzieści osób najprawdopodobniej będzie do nas wracać i będzie nas dopytywać. No i możemy się obudzić w świecie, w którym codziennie ktoś coś od nas chce wywiera presję. Tutaj z praktyki wiem, że praca pod presją może spowodować, że zdolność efektywnej pracy drastycznie spadnie.

Kuba: I niektórzy mogą się unieść, jak powiedzą – nikt nikomu nic nie obiecywał, ja to tylko wpuściłem do Backlogu. No i tutaj się kłania właśnie to jakim narzędziem Backlog Produktu jest dla nas, a jak jest rozumiany przez inne osoby w firmie. I to może być częściowo robota Product Ownera, to może być też rola dla Scrum Mastera, żeby wyjaśniać na czym polega funkcja Backlogu Produktu i też troszkę dopowiedzieć może z jakich powodów odmawiamy, z jakich powodów skupiamy się mocno na tej wizji naszego produktu. Jaka ona w ogóle jest? Dlaczego pewne rzeczy będą odrzucane nawet bez wielkiego wchodzenia w szczegóły? A niektóre pewnie jak wejdziemy w szczegóły i dopiero wtedy odrzucimy. Jeszcze jedna rzecz, która mi przychodzi do głowy, gdy myślę o tym dodawaniu elementów do Backlogu Produktu to taka refleksja dla samego siebie. Jeśli jesteś Product Ownerem, refleksja dla Twojego Product Ownera, jeśli jesteś Scrum Masterem lub refleksja dla managera, jeśli to pod Tobą w strukturze organizacyjnej są zespoły scrumowe. Kiedy ostatni raz odrzuciłeś lub odrzuciłaś elementy Backlogu Produktu? Jak często to robisz? Czy w ogóle masz prawo to robić? Tutaj niestety może się okazać, że jest prosta zależność pomiędzy słabymi elementami Backlogu Produktu, a właśnie uprawnieniem Product Ownera do decydowania o tym, co jest do zrobienia w produkcie. No i jeśli tego uprawnienia do decydowania nie ma to wiele z tych poprzednich naszych uwag też może czasem się okazać po prostu trochę takich pustych. No bo w sumie wszystko jedno co robimy. Wszystko jedno w jakiej kolejności. Wszystko jedno jak jest przygotowane. Jeśli ta osoba, która ma decydować autentycznym decydentem nie jest. Tutaj trochę tak na koniec odcinka zostawiliśmy sobie ten punkt, ale on może być bardzo kluczowy, bardzo istotny i bardzo trudny do naprawienia, jeśli tak w organizacji jest to poukładane.

Jacek: Ostatnia porada na dzisiaj to też taka porada trochę nieoczywista, przynajmniej na bazie moich obserwacji, czyli: Regularnie czyść Backlog Produktu. Tak jak tutaj w tym punkcie piątym staraliśmy się pokazać, że możemy ograniczyć ten strumień wejściowy, to takim kolejnym poziomem optymalizacji jest też przyglądanie się czy aby na pewno wszystkie te elementy, które mamy w Backlogu są nadal aktualne. Zastanowiłbym się nad tym, czy pewne elementy nie są już przeterminowane. W sensie ktoś je zgłosił dawno temu i właściwie już o tym zapomniał, albo być może są to pewne rzeczy, które są nieaktualne, czyli na moment zgłoszenia miały sens, ale Święta Wielkanocne się skończyły, no więc kreacja z zającem po prostu traci swój sens. Czy też nie ma pewnej formy duplikatów, czyli z rozpędu dodaliśmy nawet sami jeszcze raz, bo Backlog miał trzysta elementów i nie sprawdziliśmy, czy to istnieje czy nie istnieje.Tak więc taką regularną bym powiedział higienę czy aby na pewno wszystko w tym Backlogu potrzebujemy jest nam potrzebne. To jest na pewno coś co byśmy rekomendowali.

Kuba: Często przyczyną tego, że takie rzeczy się dzieją jest to, że w jednym Backlogu pracujemy dłuższy czas. Stąd taki osad, czy takie śmieciuszki się odkładają gdzieś na dole, a my ciągle patrzymy na górę Backlogu, bo to jest nasze najważniejsze skupienie. Tak najwięcej się dzieje. Tu jest uwaga biznesowa i często ten drugi, trzeci ekran gdzieś tam na dole nie jest już aż tak zaopiekowany. W praktyce proponuję, żeby sobie ustawić przypomnienie, albo być może w parze gdzieś tam Product Owner – Scrum Master, bo może to nie jest czynność, do której bym angażował cały zespół. Po prostu się umówić na jakieś regularne – na przykład kwartalne, czy comiesięczne spotkanie, na którym po prostu jesteśmy bardzo brutalni. Włączamy sobie taki agresywny tryb usuwania, czy wywalania na zasadzie – nie będziesz tego potrzebować. Trochę jak sprzątanie garażu. Ja sam tak garażu nie wysprzątam jak z żoną i pewnie to jest ciężka metafora, i wtedy po prostu nastawić się na to, że wywalamy. Jak się okaże, że wywalimy trochę za dużo, po pierwsze na pewno jest jakieś archiwum, po drugie jak będzie ważne to jeszcze to wróci, albo sobie przypomnimy, odtworzymy. Natomiast jest taki jakiś psychologiczny aspekt, z którym się obaj z Jackiem zgadzamy, że długiej listy rzeczy do zrobienia sprawiają takie wrażenie, że jest tam tak dużo, że nas przytłacza. Po czym jak się popatrzy w szczegóły to się okaże, że to już nie aktualne, to już zrobiliśmy, to zapomnieliśmy dodać, to zapomnieliśmy podzielić i się okazuje, że taki ten słoń, który stoi przed nami wydaje się o wiele większy niż jest on większy w praktyce.

Jacek: No jak powiedziałeś o tym, że być może tych rzeczy nie potrzebujemy to może też praktyczna porada od 37signals. W jednej z książek pisali o tym, żeby nie dodawać rzeczy na listę, jeżeli przychodzą od naszych klientów jakieś takie pomysły czy zapotrzebowania. Bo jeżeli one są naprawdę ważne, no to regularnie będą nam o tym ludzie przypominać. Być może skrajne podejście, ale też tak fajnie pokazujące, że tych najważniejszych rzecz mała szansa jest, że je przeoczymy. No więc cały ten plankton, o którym powiedziałeś w większości przypadków możemy regularnie usuwać.Tak jak mówiłeś o tym takim wskaźniku, ile razy odmówiłem, to można też sobie wprowadzić też jakąś taką liczbę, która nam będzie pokazywać z jednej strony jak nam ten Backlog Produktu przyrasta, z drugiej strony czy my z tego Backlogu coś usuwamy? Jak nie no to na pewno jest jakiś temat do zastanowienia się.

Kuba: To podsumowując ten odcinek. Zdefiniowaliśmy czym jest Backlog Produktu i przekazaliśmy sześć porad na temat tego jak robić ten Backlog porządnie. Powtórzę te porady. Zaangażuj Zespół Developerski w tworzenie Backlogu Produktu. Bądź przygotowany na kolejny Sprint. Miej przygotowaną kolejną rzecz do zrobienia z perspektywy więcej niż jeden Sprint. Eksperymentuj z formą Backlogu Produktu. Okaż asertywność przy dodawaniu elementów do Backlogu Produktu. Regularnie czyść Backlog Produktu.

Jacek: Na koniec mamy do Ciebie z Kubą prośbę. Chodzą nam po głowie nowe pomysły związane z podcastem. Czujemy, że trochę brakuje nam informacji o naszych słuchaczach. Z tego powodu przygotowaliśmy krótką ankietę, którą możesz znaleźć na stronie porzadnyagile.pl/ankieta. Chcielibyśmy Cię z Kubą do wypełnienia tej ankiety zaprosić.

Kuba: Wypełnienie nie powinno Ci zająć więcej niż parę minut. Jest to kilkanaście prostych pytań, z których odpowiedzi pozwolą nam dostarczać lepsze treści dla Ciebie. Na odpowiedzi czekamy do 8 lipca, ale nie odkładaj wypełnienia tej ankiety na ostatnią chwilę.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.