Backlog Produktu to — obok Backlogu Sprintu oraz Przyrostu — jeden z trzech podstawowych artefaktów w Scrumie. Jest to uporządkowana lista wszystkich rzeczy, które w danym momencie uznajemy za warte zrealizowania w obrębie konkretnego produktu. Oznacza to, że nowe funkcjonalności, zmiany, błędy czy zadania związane ze spłacaniem długu technologicznego, powinny być zawarte w Backlogu Produktu, aby Właściciel Produktu oraz interesariusze mieli jasny obraz prac związanych z produktem.
Za uporządkowanie, zawartość oraz zarządzanie Backlogiem Produktu odpowiedzialny jest Właściciel Produktu. Może on samodzielnie zarządzać Backlogiem Produktu lub zlecać to zadanie Zespołowi Deweloperskiemu. W praktyce można spotkać Właścicieli Produktów, którzy samodzielnie umieszczają elementy w Backlogu Produktu, jak i takich, którzy zlecają to zadanie Zespołowi Deweloperskiemu lub umożliwiają zrobienie tego szeroko rozumianym interesariuszom. W tym ostatnim przypadku, taki element jest oczywiście wyłącznie zaproszeniem do rozmowy i zwykle wymaga uszczegółowienia.
Backlog Produktu to żyjący artefakt
W odróżnieniu od klasycznej dokumentacji projektowej, Backlog Produktu nie jest ostateczną, zatwierdzoną wersją wymagań, tylko zmienia się wraz ze zwiększaniem się wiedzy Zespołu Scrumowego na temat potrzeb oraz oczekiwań końcowych użytkowników.
Przykładową, chociaż nie jedyną okazją do zdobywania takich informacji, jest Przegląd Sprintu, podczas którego interesariusze dokonują inspekcji Przyrostu produktu i dzielą się informacją zwrotną na bazie tego, co zaprezentował im Zespół Scrumowy. Na bazie zdobytych Informacji zachodzi proces adaptacji, polegający na zaktualizowaniu Backlogu Produktu o nowo zdobyte informacje. Powoduje to, że nauka zdobywana przez Zespół Scrumowy co Sprint jest do wykorzystywania od zaraz w kolejnym Sprincie.
Backlog Produktu jest dostępny i przejrzysty
Odpowiedzialnością Właściciela Produktu jest zapewnienie, że Backlog Produktu jest dostępny, przejrzysty i jasny dla wszystkich. Dostępności Backlogu Produktu oznacza, że istnieje jednoznacznie określone miejsce w którym się znajduje, oraz że jest ono znane oraz osiągalne dla interesariuszów. Przykładowo, Backlog Produktu zapisany w na dysku twardym Właściciela Produktu nie spełnia warunku dostępności.
Z kolei przejrzystość i jasność Backlogu Produktu oznacza, że jest on prowadzony w takiej formie, która zapewnia jednoznaczny sposób interpretacji informacji tam zapisanych. Jeżeli ktokolwiek z Zespołu Deweloperskiego lub interesariuszy nie jest w stanie poprawnie czytać z niego informacji, może to oznaczać, że brakuje ustalonych wspólnych standardów dotyczących tego, jak elementy Backlogu Produktu będę utrzymywane.
Proces doskonalenia Backlogu Produktu
Właściwie zarządzany Backlog Produktu podlega ciągłemu procesowi doskonalenia (ang. refinement), polegającemu na dodawaniu i usuwaniu elementów oraz uzupełnianiu ich o niezbędne szczegóły. Dodawane są również oszacowania elementów (popularnie zwane estymatami), ich wartość biznesowa oraz nadawana jest odpowiednia kolejność w Backlogu Produktu. Czynności te wg autorów Scruma nie zajmują zwykle więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie. Praktyka pokazuje, że w zależności od wielu czynników, m.in. od aktualnego stanu Backlogu Produktu, złożoności produktu czy też aktualnego stanu wiedzy Zespołu Scrumowego, czas ten może się zarówno skracać jak i znacząco wydłużać.
W konsekwencji doskonalenia Backlogu Produktu elementy znajdujące się wyżej są zwykle bardziej szczegółowo opisane, co wpływa na większą precyzję ich oszacowań. Elementy znajdujące się na samej górze Backlogu Produktu spełniają zwykle definicję przygotowania (ang. definition of ready) określoną przez Zespół Scrumowy. Oznacza to, że są na tyle jasne i kompletne, że zespół może je wziąć pod uwagę podczas prognozowania zakresu prac w trakcie Planowania Sprintu.
Z kolei elementy znajdujące się nisko w Backlogu Produktu — jako, że ich implementacja jest oddalona w czasie — zwykle są bardziej ogólne, a oszacowania mogą znacząco ulec zmianie w przyszłości. W konsekwencji elementy te nie są zwykle przygotowane na tyle, aby Zespół Deweloperski był w stanie zrealizować je podczas pojedynczego Sprintu.
Forma zapisu elementów Backlogu Produktu
Oficjalny Przewodnik po Scrumie nie wskazuje, w jakiej formie powinny być wyrażane elementy Backlogu Produktu. Pozostaje to w gestii zespołu, aby wybrać dogodny dla nich format zapisu.
W praktyce, najczęściej spotykany format zapisu elementów Backlogu Produktu to forma historii użytkownika (ang. user story), wywodzący się z Extreme Programming. Historie użytkownika wyrażają jego potrzeby i oczekiwania w formacie: JAKO <użytkownik> CHCĘ <potrzeba> TAK, ABY <korzyść>.
Ta zwięzła forma ma na celu wzbudzenie dyskusji w Zespole Scrumowym, której celem jest dogłębne zrozumienie, co kryje się za tym krótkim zdaniem. Szczegóły historii użytkownika — często wyrażane w postaci kryteriów akceptacji (ang. acceptance criteria) — wyłaniają się w trakcie dyskusji w obrębie Zespołu Scrumowego.
Narzędzia do utrzymywania Backlogu Produktu
Istnieją dwie główne możliwości utrzymywania Backlogu Produktu: w wersji fizycznej lub elektronicznej.
W pierwszej opcji elementy Backlogu Produktu są zapisywane przykładowo na kartkach typu post-it, a następnie przyklejane na ścianę, tablicę suchościeralną lub przygotowany wcześniej odpowiedni duży arkusz folii elektrostatycznej lub zwykłego papieru. Plusem takiego podejścia jest możliwość spojrzenia na Backlog Produktu jako całość, robiąc kilka kroków w tył od miejsca, w którym się znajduje. Dodatkowo, łatwość przesuwania kartek i dowolnego ich aranżowania zwykle pobudza dyskusję oraz pozwala na analizowanie różnorodnych scenariuszy dalszego rozwoju produktu. Minusem jest problematyczna synchronizacja Backlogu Produktu pomiędzy różnymi lokalizacjami, gdy mamy do czynienia z zespołem rozproszonym geograficznie.
Z kolei w wersji elektronicznej mamy do dyspozycji dużą ilość darmowych oraz komercyjnych narzędzi, takich jak JIRA, Trello czy też popularny Microsoft Excel. Plusem w tym przypadku jest dostępność tak utrzymywanego Backlogu Produktu, który jest osiągalny w sposób ciągły dla zainteresowanych z niemal dowolnej lokalizacji oraz z dowolnego urządzenia. Minusem jest słabsza całościowa widoczność produktu, ponieważ zwykle aplikacje pozwalają wyświetlić wyłącznie wybrany fragment Backlogu Produktu, którego rozmiar ograniczony jest przekątną ekranu, którą dysponujemy. Dodatkowo, dyskusje toczone wokół telewizora lub dużego monitora są zwykle mniej interaktywne niż te przeprowadzane przy użyciu fizycznego Backlogu Produktu.
Posłuchaj też 39. odcinka podcastu Porządny Agile, którego tematem jest Porządny Backlog Produktu i odcinka 81. Dzielenie elementów Backlogu Produktu