Backlog produktu: wskazówki dotyczące tworzenia oraz ustalania priorytetów

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 harmonogramu produktu i jego wymagań lista prac zespołu programistycznego. Najważniejsze elementy są widoczne na górze 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).

W ramach postępowania Scrum backlog produktu Scrum to uporządkowana i starannie prowadzona lista używana przez product ownera Scrum do kierowania zadaniami zespołu programistycznego.

Wypróbuj tablice Scrum Jira

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

Należycie prowadzony backlog produktu może przynieść wiele korzyści zespołowi programistycznemu. Najważniejsze z nich:

• Sprawniejsze ustalanie priorytetów: backlog produktu pomaga się upewnić, że najistotniejsze zadania są wykonywane w pierwszej kolejności.
• Zwiększona wydajność: ustalając priorytety w oparciu o opinie klientów i cele biznesowe, zespoły mogą się upewnić, że pracują nad najcenniejszymi zadaniami.
• Lepsza komunikacja: backlog produktu sprawia, że wszyscy są zgodni i dążą do realizacji tych samych celów.
• Ograniczenie marnotrawstwa: nadając priorytet zadaniom w oparciu o opinie klientów i cele biznesowe, zespoły mogą zmniejszyć marnotrawstwo i upewnić się, że pracują nad wartościowymi zadaniami.
• Większe zadowolenie klienta: nadając priorytet zadaniom na podstawie opinii klientów, zespoły mogą się upewnić, że dostarczają pożądane przez klientów funkcje.

Ogólnie rzecz biorąc, należycie prowadzony backlog produktu jest niezbędny do rozwoju produktu zgodnie z metodyką Agile. Dzięki niemu zespoły pracują nad najcenniejszymi zadaniami, a wszyscy są zgodni i dążą do realizacji tych samych celów.

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)

Efektywne ustalanie priorytetów dla backlogu produktu sprawia, że najważniejsze zadania są realizowane w pierwszej kolejności, równoważąc autonomię zespołu z wymaganiami product ownera.

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.

Tworzenie backlogu produktu jest kluczowym krokiem w rozwoju produktu zgodnie z metodyką Agile. Obejmuje ono opracowanie harmonogramu produktu, sporządzenie listy elementów backlogu produktu oraz komunikowanie się z zespołem.

Harmonogram produktu to ogólny plan przedstawiający wizję, cele i zadania produktu. Służy on jako podstawa backlogu produktu i pomaga się upewnić, że wszyscy są zgodni i dążą do realizacji tych samych celów.

Aby stworzyć harmonogram produktu, zdefiniuj wizję i misję produktu. Następnie określ kluczowe cele główne i dodatkowe, które należy osiągnąć. Na koniec podziel cele główne na mniejsze, wykonalne zadania, które można dodać do backlogu produktu.

Po wdrożeniu harmonogramu produktu pora stworzyć listę elementów backlogu produktu. Elementy te mogą obejmować funkcje, historyjki użytkowników, błędy, zmiany projektowe i dług techniczny.

Podczas sporządzania elementów backlogu produktu należy podać jasny opis każdego elementu oraz wszelkie istotne szczegóły, takie jak szacowany czas i wymagane zasoby. Niezbędne jest również ustalenie priorytetów dotyczących elementów na podstawie opinii klientów, wniosków i celów biznesowych. Dzięki temu zespół programistów pracuje nad zadaniami dostarczającymi największą wartość.

Efektywna komunikacja ma kluczowe znaczenie przy tworzeniu backlogu produktu. Product owner powinien ściśle współpracować z zespołem programistów, aby się upewnić, że wszyscy rozumieją backlog produktu i priorytety. Powinien on również komunikować się z innymi zespołami, takimi jak zespoły sprzedaży i marketingu, aby się upewnić, że wszyscy są zgodni i dążą do realizacji tych samych celów.

Dzięki regularnym spotkaniom i aktualizacjom wszyscy się ze sobą zgadzają, a backlog produktu jest efektywnie zarządzany.

Nadal potrzebujesz wskazówek? Zapoznaj się z darmowym szablonem backlogu produktu w Jirze.

Ustalenie priorytetów dla backlogu ma kluczowe znaczenie, gdy chcemy mieć pewność, że zespół programistów skupi się na zadaniach zapewniających maksymalny efekt. Należy do tego podejść następująco:

Różne techniki ustalania priorytetów dla backlogu, takie jak MoSCoW i punktacja ważona, mogą pomóc zespołom skutecznie zarządzać zadaniami i je porządkować. Proces ustalania priorytetów obejmuje regularną weryfikację celów i ich dostosowywanie do dynamicznego środowiska biznesowego.

• Zidentyfikuj funkcje lub rozwiązania, które będą miały najwyższą wartość dla użytkowników.
• Korzystaj z opinii klientów, ankiet lub analiz, aby dokładnie określić priorytety.

• Nadaj priorytet elementom, które wygenerują praktyczne informacje dla zespołu lub interesariuszy.
• Przykładowo wczesne przetestowanie nowej funkcji może później umożliwić zaoszczędzenie czasu i zasobów.

• Racjonalnie skomponuj swój backlog, uwzględniając szybkie korzyści i bardziej złożone, długoterminowe projekty.
• Oceń relację nakładu pracy do efektu, aby się upewnić, że zasoby są mądrze wykorzystywane.

• Określ zadania, które muszą zostać wykonane, zanim inni pracownicy będą mogli kontynuować.
• Usprawnij przepływy pracy, zajmując się najpierw pracami podstawowymi.

Niezawodne narzędzia wspierające ustalanie priorytetów dla backlogu mogą usprawnić rozwój produktu i zwiększyć wydajność. Podczas gdy product owner kieruje ustalaniem priorytetów, zaangażowanie zespołu programistów, projektantów i interesariuszy sprzyja wspólnemu zrozumieniu priorytetów. Regularne dyskusje zapewniają koordynację i usprawniają podejmowanie decyzji.

Porada eksperta: użyj ram ustalania priorytetów, takich jak MoSCoW (ang. Must have, Should-have, Could-have i Won't-have — konieczne, przydatne, możliwe i nieplanowane) lub punktacja ważona, aby podejmować obiektywne decyzje oparte na danych. Zespoły mogą wdrażać własne unikalne ramy ustalania priorytetów za pomocą elastycznej funkcji ustalania priorytetów w Jira Product Discovery.

Po zbudowaniu backlogu produktu należy go regularnie weryfikować w celu nadążenia za tempem programu. Product ownerzy powinni przeglądać backlog przed każdym spotkaniem dotyczącym planowania iteracji, aby się upewnić, że priorytety są właściwe i uwzględniono informację zwrotną z poprzedniej iteracji. Dzięki regularnym przeglądom backlogu, w kręgach Agile często nazywanemu porządkowaniem backlogu produktu, zadania są dostosowane do analiz interesariuszy, a zespół jest przygotowany do nadchodzącego sprintu (niektórzy używają terminu „porządkowanie rejestru zadań”).

W miarę powiększania backlogu product ownerzy muszą go dzielić 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 pełne historyjki użytkowników, uzgodniono współpracę z zespołami projektowym i programistycznym oraz ustalono szacunki z zespołem programistycznym.

Elementy do realizacji w perspektywie długoterminowej mogą zawierać niejasności, jednak warto zlecić ich przybliżone oszacowanie zespołowi programistycznemu, ponieważ ułatwi to ustalenie ich priorytetu. Kluczowym słowem jest tutaj „przybliżone”: 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 zmieniać priorytety prac w backlogu na podstawie opinii klienta, doprecyzowania szacunków czy pojawienia się nowych wymagań. Gdy jednak prace są już w toku, zmiany powinny być ograniczone do minimum, ponieważ zakłócają one funkcjonowanie zespołu programistów i negatywnie wpływają na jego koncentrację, przebieg prac i morale.

Porada eksperta: gdy backlog powiększy się, przekraczając długoterminowe możliwości zespołu, można zamknąć zgłoszenia, którymi zespół nigdy się nie zajmie. Na potrzeby przyszłych badań należy te zgłoszenia oznaczyć w narzędziu do śledzenia zgłoszeń konkretnym rozwiązaniem, np. „poza zakresem”.

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

• Product owner ustala priorytety dla backlogu na początku projektu, ale nie dostosowuje ich wraz z napływem informacji zwrotnej 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.

Rozsądni product ownerzy rygorystycznie porządkują backlog produktu swojego programu, aby stworzyć wiarygodny i możliwy do udostępnienia zarys zgłoszeń projektu.

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 do programu.

Backlog Agile z właściwie ustalonymi priorytetami wyjaśnia, na co zespół zamierza poświęcić czas, podkreślając widoczne i wewnętrzne zadania. Backlog produktu stanowi także podstawę planowania iteracji. W backlogu należy uwzględnić wszystkie zgłoszenia: m.in. historyjki użytkowników, błędy, zmiany projektowe, dług techniczny, wnioski klientów i czynności do wykonania wynikające z retrospektywy. W ten sposób można mieć pewność, że zgłoszenia 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 zadań do wykonania, członkowie zespołu mogą pójść na pewne kompromisy z product ownerem jeszcze przed rozpoczęciem iteracji.

Porada eksperta: product ownerzy określają w backlogu priorytet zgłoszeń, podczas gdy zespół programistów decyduje o prędkości realizacji. Nowym product ownerom, którzy próbują „wcisnąć” zespołowi pracę, ta relacja może wydać się luźna. W tym artykule wyjaśniono limity i przepływ prac w toku.