Backlog produktu — czym jest i jak go stworzyć

Backlog Agile z dobrze ustalonymi priorytetami nie tylko ułatwia planowanie wydań i iteracji, ale także informuje o wszystkim, na co zespół planuje poświęcić czas — łącznie z pracami wewnętrznymi, których klient nigdy nawet nie zauważy. To ułatwia określenie oczekiwań względem interesariuszy i innych zespołów, zwłaszcza jeśli przysparzają Ci dodatkowej pracy, i sprawia, że czas pracy inżynierskiej staje się środkiem trwałym.

Backlog produktu to uporządkowana pod względem priorytetów i wynikająca z planu działań dotyczącego produktu oraz wymagań lista prac dla zespołu programistycznego. Najważniejsze elementy są widoczne na szczycie backlogu produktu, aby zespół wiedział, co powinien dostarczyć w pierwszej kolejności. Zespół programistyczny nie realizuje prac z backlogu w tempie narzuconym przez product ownera, a product owner nie wypycha prac do zespołu programistycznego. Zamiast tego zespół programistyczny pobiera prace z backlogu produktu, gdy pozwala mu na to jego potencjał wykonawczy, w sposób ciągły (Kanban) lub w iteracjach (Scrum).

Harmonogram i wymagania zespołu stanowią podstawę backlog produktu. Inicjatywy w harmonogramie dzielą się na kilka epików, a każdy epik zawiera kilka wymagań i historyjek użytkowników. Przyjrzyjmy się harmonogramowi fikcyjnego produktu o nazwie Teams in Space.

Witryna internetowa Teams in Space jest pierwszą inicjatywą w harmonogramie, dlatego chcemy podzielić ją na epiki (zaznaczone tutaj na zielono, niebiesko i turkusowo), a do każdego z nich przypisać historyjki użytkowników.

Następnie product owner porządkuje poszczególne historyjki użytkowników w jedną listę przeznaczoną dla zespołu programistycznego. Product owner może zdecydować się na dostarczenie w pierwszej kolejności gotowego epiku (z lewej). Może jednak się zdarzyć, że z punktu widzenia programu ważniejsze będzie przetestowanie funkcji rezerwacji lotów po obniżonej cenie, co wymaga uwzględnienia historyjek z kilku epików (z prawej). Poniżej zaprezentowano obydwa przykłady.

Jakie czynniki mogą wpływać na priorytety ustalane przez product ownera?

• Priorytet klienta
• Pilna potrzeba uzyskania informacji zwrotnych
• Względna trudność wdrożenia
• Relacje symbiotyczne między jednostkami pracy (np. B będzie łatwiejsze, jeśli najpierw zrobimy A)

Choć ustalenie priorytetów w backlogu należy do product ownera, nie robi on tego w próżni. Skuteczni product ownerzy sięgają do uwag i opinii klientów, projektantów oraz programistów, aby zoptymalizować obciążenie pracą poszczególnych członków zespołu i dostarczanie produktu.

Po utworzeniu backlogu produktu ważne jest, aby regularnie go weryfikować w celu nadążenia za tempem programu. Product ownerzy powinny przeglądać backlog przed każdym spotkaniem dotyczącym planowania iteracji, aby się upewnić, że priorytety są właściwe i uwzględniono informacje zwrotne z poprzedniej iteracji. Regularne sprawdzanie backlogu bywa w kręgach Agile nazywane „porządkowaniem backlogu” (a niektórzy posługują się pojęciem dopracowywania backlogu).

W miarę powiększania backlogu, product ownerzy muszą go pogrupować na elementy realizowane w perspektywie krótko- i długoterminowej. Elementy należące do pierwszej grupy muszą być w pełni dopracowane, zanim oznaczy się je w ten sposób. Oznacza to, że opracowano historyjki użytkowników, uzgodniono współpracę z działem projektowym i programistycznym oraz ustalono szacunki z zespołem programistycznym. Elementy do realizacji w perspektywie długoterminowej mogą zawierać pewne niejasności, choć dobrym pomysłem jest zlecenie ich przybliżonego oszacowania zespołowi programistycznemu, ponieważ ułatwi to ustalenie ich priorytetu. Kluczowym słowem jest tutaj „przybliżonego”: szacunki ulegną zmianie, gdy zespół dokładnie zapozna się z tymi elementami i przystąpi do ich realizacji.

Backlog służy jako ogniwo łączące product ownera z zespołem programistycznym. Product owner może swobodnie zmieniać priorytety prac w backlogu w dowolnej chwili, w wyniku opinii klienta, doprecyzowania szacunków czy pojawienia się nowych wymagań. Gdy jednak prace są już w toku, należy ograniczać liczbę zmian do minimum, ponieważ zakłócają one funkcjonowanie zespołu i negatywnie wpływają na koncentrację, przepływ i morale.

Błędy, których nie należy powielać

• Ustalenie przez product owner priorytetów w backlogu na początku projektu, ale powstrzymanie się od wprowadzania w nich modyfikacji na podstawie informacji zwrotnych napływających od programistów i interesariuszy.
• Ograniczenie elementów prac w backlogu do tych, które są zorientowane na klienta.
• Przechowywanie backlogu jako dokumentu lokalnego i rzadkie udostępnianie, co uniemożliwia zainteresowanym stronom dostęp do aktualnych informacji.

Doświadczeni product ownerzy rygorystycznie porządkują backlog produktu w programie tak, aby stanowił niezawodny obraz jednostek pracy w ramach projektu, który można udostępniać.

Interesariusze będą kwestionowali priorytety i tak ma być. Zachęcanie do dyskusji na temat tego, co ważne, ułatwia wzajemne uzgadnianie priorytetów. Te dyskusje wzmacniają kulturę grupowego ustalania priorytetów i sprzyjają jednolitemu nastawieniu wszystkich członków programu.

Backlog produktu stanowi także podstawę planowania iteracji. W backlogu należy uwzględnić wszystkie elementy prac: historyjki użytkowników, błędy, zmiany projektowe, dług techniczny, wnioski klientów, czynności do wykonania wynikające z retrospektywy itp. W ten sposób można mieć pewność, że elementy pracy każdego z członków zespołu zostaną uwzględnione w ogólnej dyskusji na temat każdej iteracji. Dzięki pełnej wiedzy na temat prac, które mają zostać wykonane w trakcie iteracji, członkowie zespołu mogą pójść na pewne kompromisy z product ownerem jeszcze przed rozpoczęciem iteracji.