Product Backlog jest jednym z trzech artefaktów Scruma, który umożliwia pracę w oparciu o empiryzm. Jest uporządkowaną listą przyszłych usprawnień produktu, za którą odpowiada Product Owner. I choć jest to niezwykle istotne narzędzie, tworzące przejrzystość oraz umożliwiające inspekcję i adaptację, to dbanie o niego nie powinno być sensem pracy Product Ownera. W wielu organizacjach niestety tak jest.
Czym jest Product Backlog?
Product Backlog to stale ewoluująca, uporządkowana lista elementów opisujących planowane udoskonalenia Produktu [1]. Elementy budujące Backlog (ang. Product Backlog Item, PBI) obrazują hipotezy wartości dla użytkowników i biznesu.
Product Backlog jest jedynym źródłem wymagań dla Produktu i zadań dla Zespołu Scrumowego, dzięki czemu tworzy przejrzystość procesu wytwórczego [1]. Jego elementami mogą być nowe funkcjonalności, błędy do naprawy, dług techniczny, eksperymenty czy nawet procesowe usprawnienia dla Zespołu.
Poszczególne elementy Product Backlogu powinny mieć ustalone kolejność, opis i rozmiar. Szczegóły te dodawane są podczas procesu doskonalenia Product Backlogu (Refinementów), w którym bierze udział cały Zespół Scrumowy. Poszczególni jego członkowie (w tym Product Owner i Developerzy) współpracują by zrozumieć sens omawianych elementów. Celem jest osiągnięcie wspólnego zrozumienia pracy, która jest do wykonania.
W wyniku tych rozmów Developerzy proponują rozmiar elementu. Scrum nie określa jednej metody szacowania. Możliwości jest dużo, a Zespół powinien wybrać tę metodę, która najbardziej będzie mu odpowiadać.
Szczegóły Product Backlogu
Product Backlog jako lista, ma tę charakterystyczną cechę, że jego górna część składa się z elementów o wysokim poziomie szczegółów. Im dalej w głąb Backlogu, tym elementy mają coraz mniejszą ilość szczegółów. Jest to istotne z punktu widzenia empiryzmu.
Stratą czasu jest opracowywanie i szacowanie elementów z niskim priorytetem w Backlogu, gdyż do czasu ich realizacji nasze złożone środowisko może wymusić obranie innego kierunku rozwoju. Zmiany rynkowe, otrzymane informacje zwrotne czy wybrana kolejność realizacji zadań mogą mieć wpływ na kształt elementów „z dołu” Backlogu. W skrajnym przypadku Product Owner może zrezygnować z realizacji wcześniej stworzonych elementów Backlogu.
Ktoś mógłby spytać – ile elementów powinno mieć wysoki poziom szczegółów?
Nie ma jednej dobrej odpowiedzi. Powinniśmy znaleźć odpowiedni balans, który zapewni, że Zespoły będa miały odpowiednio dużo elementów gotowych do realizacji w Sprincie, a praca związana z dodawaniem szczegółów do oddalonych w czasie elementów nie szła na marne [7]. Typowo będzie to liczba elementów, które wystarczają dla Zespołu na około 2-3 Sprinty.
Product Backlog powinien być odpowiednio mały i umożliwiający działanie [8].
Product BACKLOG A EMPIRYZM
Wszystkie trzy artefakty zdefiniowane w Scrumie mają za zadanie zwiększać transparencję kluczowych informacji. Dzięki temu każdy kto podejmuje próbę inspekcji, ma taką samą bazę do podejmowania decyzji o koniecznych adaptacjach. Nie inaczej jest w przypadku Product Backlogu.
Product Backlog a przejrzystość
Przejrzystość to nie tylko widoczność, ale również wspólne rozumienie [2]. Product Backlog przejrzyście ukazuje co będzie realizowane w Produkcie i w jakiej kolejności. Pozwala na łatwiejszą komunikację między Zespołem Scrumowym a Interesariuszami, dzięki tworzeniu wspólnego rozumienia planów na rozwój produktu.
Product Backlog z dostateczną ilością szczegółów w górnej jego części, pozwala na tworzenie prognoz oraz trendów dotyczących czasu dostarczenia poszczególnych fragmentów Produktu (niezależnie od stosowanej metody estymacji). Pomaga to kontrolować, czy jesteśmy na dobrej drodze do osiągnięcia Celu Produktu.
Backlog służy jako narzędzie do budowania przejrzystości podczas wszystkich wydarzeń Scrumowych: od Planowania, poprzez Daily Scrum, kończąc na Sprint Review i Retrospektywie.
Product Backlog a inspekcja i adaptacja
Product Backlog umożliwia inspekcję. Patrząc na listę możliwości, które pewnego dnia będą dostępne w Produkcie, możemy weryfikować, czy pozwolą one osiągnąć Celu Produktu, czy realizują strategię i przybliżają nas do wizji [3]. Taka inspekcja pomaga odpowiadać na pytanie, czy nowe możliwości Produktu będą spełniać potrzeby i pragnienia jego użytkowników.
Backlog jest również narzędziem, które pozwala obrazować proces adaptacji. Dzięki nanoszeniu zmian do Product Backlogu, które wynikają z wniosków wyciągniętych z procesu inspekcji, możemy minimalizować odchylenia naszej drogi ku osiągnięciu Celu Produktu. Product Backlog jest zatem tworem, który może się stale zmieniać, niezależnie od aktualnego etapu pracy [4].
PRODUCT BACKLOG NARZĘDZIEM PRODUCT OWNERA
Za Product Backlog odpowiada Product Owner. Z jego pomocą może przekazywać swoją wizję jak Produkt osiągnie stawiane przed nim cele. Tworzy elementy Product Backlogu, organizuje je w przejrzysty i zrozumiały sposób. Product Owner podejmuje decyzje o kolejności wykonywania zadań w Produkcie, co odzwierciedlane jest za pomocą kolejności poszczególnych elementów w Backlogu.
I choć Product Backlog jest kojarzony głównie z rolą Product Ownera, to osoba ją pełniąca nie powinna być jedyną, która dba o Backlog.
Ważną częścią pracy Zespołu Scrumowego są wspólne Refinementy, na których dopracowywane są szczegóły poszczególnych elementów Product Backlogu. Dobre Refinementy pozwolą nie tylko dodać do Backlogu niezbędne szczegóły, ale również ułatwią planowanie i pozwolą tworzyć prognozy [6].
Współpraca całego Zespołu podczas Refinementów umożliwia tworzenie lepszych rozwiązań w Produkcie, niż gdyby wymyślał je jedynie Product Owner [6]. Otwarta współpraca z Developerami, którzy czują odpowiedzialność za Produkt, może przynieść wiele dobrego. Podczas spotkań, każdy przynosi pomysły, swoje doświadczenia i wiedzę, a proponując rozwiązania, wnosi do grupy wiele inspiracji. Developerzy przynoszą do dyskusji ważną perspektywę technologiczną.
Product Owner nie jest zarządcą Product Backlogu
Często rola Product Ownera jest ograniczana jedynie do roli zarządcy Product Backlogu. Taki Product Owner dba o idealny porządek w Backlogu, tworzy perfekcyjne historyjki użytkownika, jest jedyną osobą, która może tworzyć i zamykać elementy Product Backlogu, po wykonaniu kontroli ich jakości [5]. Nie zawsze idzie za tym moc decyzyjności.
Takie podejście będzie odciągać Product Ownera od jego najważniejszego zadania, czyli podejmowania decyzji zapewniających maksymalizację wartości Produktu. By podejmować dobre decyzje Product Owner musi mieć stały kontakt z użytkownikami Produktu i Interesariuszami, być zaangażowany w proces odkrywania Produktu, analizować rynek, czy metryki wartości. Zadania te mogą jedynie skorzystać, jeżeli część zadań związanych z zarządzaniem Backlogiem zostanie oddelegowana (na co Scrum daje przyzwolenie!).
Oddelegowanie części zadań związanych z zarządzaniem Backlogiem do Develperów da im większą moc sprawczości, spowoduje wzrost odpowiedzialności za Produkt, będzie wspierać samoorganizację. Product Ownerowi da czas na robienie tego co ważne.
PODSUMOWANIE
Product Backlog jest jednym z artefaktów Scruma oraz ważnym elementem związanym z codzienną pracą Product Ownera. Tworzy przejrzystość procesu oraz planów na rozwój Produktu. Umożliwia inspekcję i adaptację. Pomaga budować wspólne rozumienie wśród członków Zespołu Scrumowego oraz Interesariuszy. Ułatwia współpracę. Zarządzanie Product Backlogiem nie może jednak stać się sensem pracy Product Ownera. Jeżeli tak się dzieje, zabiera to skupienie Product Ownera od tego co ważne – empirycznego podejmowania decyzji o usprawnieniach, które będą maksymalizować wartość Produktu.
BILIOGRAFIA
[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[2] The importance of Transparency and the Product Backlog (06); https://www.scrum.org/resources/blog/importance-transparency-and-product-backlog-06
[3] Inspection and the Product Backlog (17); https://www.scrum.org/resources/blog/inspection-and-product-backlog-17
[4] How the Product Backlog supports Adaptation (28); https://www.scrum.org/resources/blog/how-product-backlog-supports-adaptation-28
[5] Should the Product Owner ‘close’ Product Backlog items?; https://www.scrum.org/resources/blog/should-product-owner-close-product-backlog-items
[6] 5 Reasons why Refining your Product Backlog is Worth the Time; https://www.scrum.org/resources/blog/5-reasons-why-refining-your-product-backlog-worth-time
[7] Product Backlog refinement: How far is too far?; https://www.scrum.org/resources/blog/product-backlog-refinement-how-far-too-far
[8] YDS: Can You Have Too Many Product Backlog Items?; https://www.scrum.org/resources/blog/yds-can-you-have-too-many-product-backlog-items