O “trzech najważniejszych” artefaktach Scruma pisałyśmy już jakiś czas temu. Pora trochę bardziej szczegółowo omówić pierwszy z nich. Backlog Produktu, bo to o nim mowa, jest niezbędny do tego, żeby istniały dwa kolejne – Backlog Sprintu oraz Przyrost. Scrum Guide jasno mówi o relacjach pomiędzy nimi i o tym, jakie warunki muszą spełniać by wspierać Transparentność, Inspekcję i Adaptację, czyli filary frameworku.

Czym jest Backlog Produktu?

Stojąc w obliczu stworzenia produktu zastanawiasz się pewnie jak powinien wyglądać i działać. Przychodzi Ci do głowy wiele pomysłów. Jedne są bardziej związane z podstawowym działaniem produktu, inne są pewnego rodzaju ulepszeniami, które mogą sprawić, że produkt będzie bardziej atrakcyjny na rynku. Wszystko to, to właśnie Backlog Produktu, za który Ty jako jego Właściciel jesteś odpowiedzialny. Ważne, żeby nie był on jednak tylko wyobrażeniem w Twoich myślach. Musi być przeniesiony w miejsce dostępne dla wszystkich, którzy będą pracowali nad wytworzeniem owego produktu. Przy założeniu, że cały Zespół Scrumowy pracuje w jednym pomieszczeniu, może to być nawet zbiór kartek, post-in, przyczepionych na ścianie. Nie ma znaczenia czy będzie on w formie papierowej czy zdigitalizowanej (przykładowo na Jirze czy Azure Boards). Istotne, żeby był dostępny i zrozumiały dla wszystkich zainteresowanych rozwojem produktu.

Scrum.org

Do stworzenia elementów Backlogu Produktu (PBI – Product Backlog Item) możesz wykorzystać wiele technik – Design Thinking, Event Storming, Brainstorming – narzędzi jest naprawdę dużo. Nie są one jednak konieczne. Możesz zdefiniować PBI w dowolny sposób. Co ważne Backlog Produktu nie jest zamkniętą listą, a stale otwartą czekającą na nowe elementy. Istnieje on tak długo dopóki produkt, który budujemy również istnieje. Wspierana jest dzięki temu ciągła inspekcja i adaptacja realizowanego przedsięwzięcia. Jest to miejsce gdzie powinna stale trafiać informacja zwrotna od użytkownika końcowego, interesariuszy i wszystkich zaangażowanych.

Jaką formę może przybierać Backlog Produktu?

Jak możemy przeczytać w Scrum Guide wszystkie elementy listy powinny być odpowiednio opisane i uporządkowane, posiadać wartość oraz estymatę. 

Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.

Scrum Guide, 2017

Opis powinien być na tyle szczegółowy, by każdy zrozumiał co dany PBI ma wprowadzać do całości. Nie powinien jednak zamykać Zespołowi Deweloperskiemu (DT) drogi do wypracowania jego realizacji. Mam na myśli to, że PBI później wypełniają zawartość Backlogu Sprintu, którego właścicielem jest właśnie DT. Przez własność mam na mysli to, ze DT może w dowolny, spójny sposób dobierać techniki, narzędzia czy budować rozwiązania, tak aby zrealizować przedstawione założenia. W Scrum tylko Zespół Deweloperski może decydować w jaki sposób zrealizuje dane zadania. Trzeba więc umieć wyważyć jaki opis będzie wystarczający. Najlepiej tego dokonać metodą prób i błędów, czyli empirycznie podejść do tworzenia PB wybierając rozwiązanie dogodne dla wszystkich.

User Stories

Bardzo częstym sposobem na jego wypełnianie jest wykorzystanie User Stories (US), czyli historyjek jakie będzie mógł zrealizować użytkownik w produkcie. Z mojego doświadczenia wynika, że jest to bardzo przejrzysta i jasna forma. Zespół Deweloperski wie co ma zrealizować i jaka wartość za tym stoi dla użytkownika końcowego. Z kolei Właścicielowi Produktu dużo łatwiej jest budować produkt właśnie z tej perspektywy mającby chociaż na uwadzę ciałgy kontkat z interesariuszami. Zapewnia to transparentność w całym Zespole. US nie są jednak konieczne, tak jak wspomniałam, elementy Backlogu Produktu mogą przybierać dowolną, zrozumiałam dla wszystkich formę.

Ważne jest to, że ten artefakt jest ciągle żywy, że powinien być stale wypełniany nowymi elementami, a obecne PBI powinny być modyfikowane jeżeli zajdzie taka potrzeba. Konieczne jest to, aby Właściciel Produktu dbał o uporządkowanie tej listy. Jej najistotniejsze i najlepiej znane elementy, powinny znajdować się na górze. Z kolei te usprawnienia czy funkcjonalności, które nie mają aż tak dużego znaczenia dla biznesu powinny znaleźć się niżej w hierarchii.

Wartość i oszacowanie

Zwłaszcza górna część Backlogu Produktu powinna posiadać też wartość i oszacowanie. Przez wartość rozumiemy tutaj wpływ na biznes, zarówno ten pozytywny jak i ewentualne konsekwencje w przypadku braku zrealizowania danego zadania. W praktyce często sprowadza się to do wartości liczbowej. Przykładowo 5 może oznaczać że dany PB jest bardzo istotny dla działania i rozwoju produktu, z kolei 1, że chcemy zrealizować dane zadanie, ale w późniejszych iteracjach. Jednak nie tylko opis, priorytety i wartość pozwalają zadecydować co będzie realizowane w kolejnych sprintach.

Kolejnym niezbędnym elementem jest oszacowanie złożoności, skomplikowania i czasochłonności elementów backlogu produktu, czyli estymata. Scrum Guide nie definiuje w jaki sposób estymacja ma być zrealizowana, ale mówi o konieczności jej istnienia. Pisałyśmy już o micie związanym z obowiązkiem estymacji w Story Points (SP). Sposób jaki wybierzemy do oszacowania PBI jest dowolny. Mogą to być dni, godziny, rozmiary koszulek, wspomniane SP czy coraz bardziej popularna technika #noestimates. Estymacje, w połączeniu z trzema wyżej wymienionymi artefaktami Backlogu Produktu, mają nam pomóc w zdefiniowaniu zakresu na przyszłe sprinty. 

Kto powinien tworzyć elementy Backlogu Produktu?

Często pierwszą myślą jaka przychodzi nam w odpowiedzi na to pytanie jest – no jak to kto? Właściciel Produktu! I faktycznie w Scrum Guide można znaleźć fragment o odpowiedzialności Product Ownera (PO) względem Backlogu Produktu:

Właściciel Produktu jest jedyną osobą odpowiedzialną za zarządzanie Backlogiem Produktu (ang. Product Backlog). Pojęcie zarządzania Backlogiem Produktu mieści w sobie:

jasne artykułowanie elementów Backlogu Produktu,
porządkowanie kolejności elementów Backlogu Produktu w sposób pozwalający jak najlepiej osiągać założone cele i misje,
zapewnianie, że Backlog Produktu jest dostępny, przejrzysty i jasny dla wszystkich, 
zapewnianie, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu.

Scrum Guide, 2017

Nie ma tutaj jednak żadnej informacji o konieczności rozpisywania przez PO backlogu, a jedynie o jego zarządzaniu. Pod listą wypunktowanych odpowiedzialności znajduje się bardzo ważne zdanie, często pomijane i nie zauważane podczas lektury:

Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.

Scrum Guide, 2017

Tak więc może się zdarzyć, że PO nie rozpisuje ani nie priorytetyzuje PBI sam, a prosi o to Zespół Deweloperski. To jednak nie zwalnia go z konieczności trzymania pieczy nad całością. Bo to on ostatecznie jest odpowiedzialny za wygląd i działanie produktu oraz maksymalizację jego wartości. Nie oznacza to jednak, że może on tylko doglądać PB nie przekazując Zespołowi Developerskiemu jak ma wyglądać produkt, którego przecież jest właścicielem. Musi on zawsze aktywnie uczestniczyć w budowaniu swojego produktu i w jasny i klarowny sposób przedstawiać swojego wymagania wszystkim członkom Zespołu Scrumowego. 

Jak zacząć pracę nad budowaniem Backlogu?

Skoro już wiemy jakie artefakty musi zawierać Backlog Produktu – opis, oszacowanie, wartość i priorytet. Jesteśmy świadomi jak powinniśmy układać elementy się w nim znajdujące oraz zdajemy sobie sprawę z tego, że jest to wiecznie aktywny i bardzo dynamiczny artefakt. Możemy spokojnie przystąpić do jego tworzenia (w przypadku nowego, dopiero kiełkującego pomysłu na produkt) lub dokonać rewizji obecnie wykorzystywanego.

Jeżeli zaczynamy pracę nad nowym produktem to w prosty sposób możemy wprowadzić dobre standardy od samego początku. Kierujcie się radami wyżej opisanymi, dokonujcie ciągłej inspekcji i adaptacji  klarowności i przejrzystości tego artefaktu w całym Zespole. Zacznijcie już od opisu pierwszego zadania. Wykorzystajcie to tego przestrzeń Refinementu. Jeżeli natomiast pracujecie już z jakimś Backlogiem Produktu to w pierwszej kolejności sprawdźcie jakie z wyżej wymienionych elementów posiada wasz backlog, a czego w nim brakuje. Dokonajcie szczerej i dokładnej rewizji i na tej podstawie wypracujcie w jaki sposób podejść do nadawania wartości poszczególnym PBI. Możecie wykorzystać wartości liczbowe o których wspomniałam, albo użyć dowolnie wypracowanego przez Was sposobu. Ważne by stworzona lista rzeczy, które mają się znaleźć w Waszym produkcie była ciągle pielęgnowana i zawierała wszystkie wymienione elementy. 

Giphy.com

Sprawdź nasze poprzednie wpisy: