Jednym z bardziej istotnych elementów w Scrumie jest zarządzanie Backlogiem Produktu. W dzisiejszym artykule przyjrzymy się temu zagadnieniu bliżej: czym jest, kto je wykonuje, jak to się robi, dlaczego jest ważne i jakie są typowe metody zarządzania.
Zarządzanie… czyli właściwie co?
Wszyscy dobrze wiemy, że Backlog Produktu to dynamicznie zmieniająca się lista wymagań i prac związanych z tworzeniem danego Produktu. Jest to jedno z fundamentalnych narzędzi w Scrumie, które pomaga zespołom utrzymywać klarowność i elastyczność w trakcie wytwarzania produktu. Backlog Produktu jest miejscem, w którym przechowuje się wszystkie pomysły, sugestie i wymagania.
Główną odpowiedzialnością za zarządzanie Backlogiem Produktu jest Product Owner. Product Owner to osoba, która reprezentuje interesy klienta lub użytkownika końcowego i jest odpowiedzialna za to, aby Backlog Produktu był zawsze uporządkowany i zawierał najważniejsze elementy do realizacji. Product Owner współpracuje blisko z interesariuszami, aby upewnić się, że Backlog jest zgodny z wizją produktu.
Wszystko to są pięknie brzmiące podstawy, ale czym właściwie jest zarządzanie Backlogiem Produktu? Czy chodzi o pisanie wymagań, utrzymywanie ich w kolejności? Co właściwie robi Product Owner?
Po co to właściwie robimy?
Zarządzanie Backlogiem Produktu jest kluczowe dla wytworzenia wartościowego produktu, a często i dla samego sukcesu „zwinnego projektu”. Przecież to Backlog Produktu pomaga utrzymać jasność co do celów, jednocześnie pozwalając na dostosowywanie się do zmieniających się potrzeb klienta. Priorytetyzacja elementów backlogu pozwala zespołowi skupić się na najważniejszych zadaniach, co zwiększa wartość produktu. Umożliwia to też bieżące śledzenie pomysłów klienta, co pomaga lepiej zrozumieć jego potrzeby.
Właściwe zarządzanie listą wymagań da nam odpowiedź na szereg pytań, na które musimy znaleźć odpowiedź jako Scrum Team. Nietrudno sobie też wyobrazić, jakie mogą być negatywne konsekwencje złego zarządzania Backlogiem Produktu. Brak wizji na rozwój, brak szerokiego spojrzenia czy nawet brak możliwości realnego zaplanowania kolejnego Sprintu to tylko niektóre z nich.
„Backlog Produktu nigdy nie jest kompletny. Jego wczesna wersja nakreśla początkowo znane i najlepiej rozumiane wymagania. Backlog Produktu ewoluuje wraz z produktem i środowiskiem, w którym ten produkt będzie używany.” – Scrum Guide 2017
Metody zarządzania Backlogiem Produktu
Sięgając do źródeł, czyli do Scrum Guide, możemy zauważyć, że zarządzanie Backlogiem Produktu jest krótką listą działań. Należą do nich zbieranie, opisywanie, porządkowanie, dzielenie i szacowanie wymagań. Większość z tych działań realizuje Product Owner, a niektóre realizujemy w całym zespole na Product Backlog Refinemencie.
PO jest (prawie) całkowicie odpowiedzialny za zbieranie wymagań. To do tej roli należy zebranie wszystkich możliwych wymagań i pomysłów dotyczących produktu. Może się to dziać w formie rozmów z klientami, analizy konkurencji lub innych źródeł informacji. Słowo „prawie” użyte jest celowo, ponieważ PO może delegować takie zadania do osób w zespole. Najczęściej będą to analitycy, którzy mają świetne kontakty z klientem bądź smykałkę do czytania rynku.
Jeżeli chodzi o priorytetyzację, to jest to już odpowiedzialność wyłącznie Product Ownera. Najważniejsze wymagania i funkcjonalności powinny być umieszczone na górze listy, aby były realizowane jako pierwsze. Tak samo dobry Product Owner regularnie będzie odbywał przeglądy Backlogu Produktu – zarówno z klientami, sponsorami i użytkownikami, jak i z całym Scrum Teamem. To drugie działanie ma swoją nazwę i jest właśnie Product Backlog Refinementem.
Nie można też zapomnieć o tym, że niektóre aspekty zarządzania backlogiem odbywają się na Planowaniu Sprintu i Sprint Review. Na obu możemy ustalać kolejność, dzielić wymagania w odpowiedzi na realia. Przy tej okazji warto też dodać, że jedyną rzeczą w kontekście zarządzania backlogiem za jaką odpowiedzialni są Deweloperzy jest szacowanie wymagań. Dzielenie wymagań to z kolei rzeczy, którą zwykle robimy razem w Scrum Teamie, ale mogą to też robić poszczególne odpowiedzialności.
Techniki? Narzędzia?
Istnieje wiele narzędzi i metod zarządzania Backlogiem Produktu. Obejmują one różne etapy, od zbierania wymagań i Product Discovery, przez analizę, dzielenie i w końcu realizację. Bardzo pomocne są proste listy, tablice, a nawet ulubiony przez wszystkich Excel. W temacie Product Discovery mamy User Story Mapping, Event Storming, Design Sprint, Impact Mapping i wiele, wiele innych technik.
Osobną kategorią są techniki priorytetyzacji – Triage, czyli klasyfikacja elementów listy wymagań według wcześniej określonych kryteriów., metoda MoSCoW, Hundred Dollar Method, ROI i wiele innych sposobów – tak różnych, jak różne są Produkty i Product Ownerzy.
W temacie narzędzi online mam nieśmiertlną Jirę, ale także Azure DevOps, Trello czy Asanę oraz mniej popularne narzędzia jak Rally czy Basecamp, które ułatwiają zarządzanie Backlogiem Produktu, śledzenie postępów i komunikację.
Tu warto podkreślić, że sam fakt wykonywania czynności związanych z zarządzaniem Backlogiem Produktu jest bardziej istotny niż używane narzędzia czy techniki. Właściwe zarządzanie listą wymagań daje komfort wszystkim uczestnikom procesu wytwarzania oprogramowania. Głównym źródłem braku komfortu jest niepewność jest głównym źródłem braku komfortu. Dobrze zarządzany backlog odpowiada na pytanie „kiedy mniej więcej będziemy się czym zajmować” – przy czym im bliższa ta data, tym to oszacowanie będzie dokładniejsze.
Ta praca nigdy się nie kończy, a Backlog Produktu zmienia się cały czas. Nie można więc powiedzieć, że zarządzanie backlogiem produktu to zadanie. To proces ciągły, który dzieje się w nieskończoność, tak długo, jak mamy wymagania.
