Backlog produktu — czym jest i jak go stworzyć

Dobry backlog produktu przypomina człowieka w dobrej kondycji: jest uporządkowany, zorganizowany i otwarty.

Dan Radigan Autor: Dan Radigan
Przeglądaj tematy

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.

Czym jest backlog produktu?

Backlog produktu to uporządkowana pod względem priorytetów, wynikająca z harmonogramu 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 wciska prac zespołowi programistycznemu. 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).

Wskazówka eksperta:

Przechowuj wszystko w jednym narzędziu do śledzenia zgłoszeń — nie używaj wielu systemów do śledzenia błędów, wymagań i jednostek prac technicznych. Prowadź w jednym backlogu wykaz wszystkich prac, którymi ma się zająć zespół programistyczny.

Zacznij od harmonogramu i wymagań

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.

Plan rozwoju zgodny z metodyką Agile | Trener Atlassian z zakresu metodyk Agile

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.

Inicjatywy i epiki Agile | Atlassian Agile Coach

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.

Epiki i historyjki Agile | Atlassian Agile Coach

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.

Jak skutecznie zarządzać backlogiem 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.

Wskazówka eksperta:

Gdy backlog rozrośnie się na tyle, że przekroczy długoterminowy potencjał wykonawczy zespołu, można zamknąć zgłoszenia, do których zespół nigdy nie dotrze. Należy je oznaczyć konkretnym rozwiązaniem, takim jak „poza zakresem”, w narzędziu do śledzenia zgłoszeń zespołu, aby można je było wykorzystać później w badaniach.

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.

Backlogi produktu utrzymują zwinność zespołów

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.

Wskazówka eksperta:

Produkt ownerzy określają w backlogu priorytet poszczególnych jednostek pracy, natomiast zespół programistyczny decyduje o prędkości realizacji backlogu. Taka relacja może być problematyczna dla nowych product ownerów, którzy próbują „wcisnąć” zespołowi pracę. Więcej na ten temat znajdziesz w naszym artykule o limitach prac w toku oraz przepływie.

Strzałka Agile

Za pomocą szablonu Jira Scrum nadaj priorytet temu, co ważne

Uzyskaj pełny wgląd we wszystkie prace do wykonania, aby móc skupić się na tych o największym wpływie.