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

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).

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

Wypróbuj tablice Scrum Jira

A well-managed product backlog can bring numerous benefits to a development team. Some of the key benefits include:

• Improved prioritization: A product backlog helps to ensure that the most critical tasks are being worked on first.

• Increased efficiency: By prioritizing tasks based on customer feedback and business objectives, teams can ensure they work on the most valuable tasks.

• Better communication: A product backlog ensures everyone is aligned and working towards the same goals.

• Reduced waste: By prioritizing tasks based on customer feedback and business objectives, teams can reduce waste and ensure that they are not working on tasks that are not valuable.

• Improved customer satisfaction: By prioritizing tasks based on customer feedback, teams can ensure they deliver customers' desired features and functionality.

Overall, a well-managed product backlog is essential for agile product development. It ensures that teams are working on the most valuable tasks and that everyone is aligned and working towards the same goals.

Harmonogram i wymagania zespołu stanowią podstawę backlogu 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 ustalenie 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 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.

Tworzenie harmonogramu produktu

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.

Opracowanie listy elementów 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ść.

Komunikacja z zespołem

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 backlogu ma kluczowe znaczenie, gdy chcemy mieć pewność, że zespół programistów skupi się na zadaniach zapewniających maksymalny efekt. Sposób podejścia: różne techniki ustalania priorytetów backlogu, takie jak MoSCoW i punktacja ważona, mogą pomóc zespołom efektywnie zarządzać zadaniami i je porządkować. Proces ustalania priorytetów obejmuje regularną weryfikację celów i ich dostosowywanie do dynamicznego środowiska biznesowego.

Krok 1. Ocena potrzeb klientów

• 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.

Krok 2. Ocena pilności informacji zwrotnej

• 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.

Krok 3. Uwzględnienie złożoności wdrożenia

• 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.

Krok 4. Uwzględnienie zależności

• 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 utworzeniu backlogu produktu należy go regularnie weryfikować, aby nadążał za tempem programu. Product ownerzy powinni przeglądać backlog przed każdym spotkaniem poświęconym planowaniu 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 nazywanych porządkowaniem rejestru zadań produktu, zadania są dostosowane do analiz interesariuszy, a zespół jest przygotowany do nadchodzącego sprintu. Niektóre zespoły używają terminu „porządkowanie rejestru zadań”.

W miarę powiększania się 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 historyjki użytkowników, sfinalizowano współpracę z zespołami projektowym i programistycznym oraz uzyskano oszacowania od tego drugiego.

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”, ponieważ 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.

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.