Backlog Produktu to zbiór wciąż nowo pojawiających się elementów (PBI – Product Backlog Item) potrzebnych do rozbudowy i poprawy jakości produktu, za których uszeregowanie odpowiada Właściciel Produktu. Z pomocą przychodzą nam różne metody priorytetyzacji. W najnowszym Scrum Guide możemy przeczytać dokładną definicję, oto jej fragment:
„Product Backlog to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia produktu. To jedyne źródło pracy podejmowanej przez Scrum Team.”
Scrum Guide, Listopad 2020
Widzimy tutaj podkreślenie ważności tego artefaktu jako jedynego źródła wymagań wprowadzanych w produkcie, co nie było dostatecznie jasno podkreślone w wersji z 2017. Owszem, to powszechnie stosowana praktyka. Wszystkie zmiany jakie mają zostać wprowadzone w produkcie powinny pojawić się właśnie w Backlogu Produktu. Niektórzy pozwalali sobie na odstępstwa. Nie raz słyszałam o sytuacjach, w których Właściciele Produktów próbowali załatwić coś na tzw „gębę”, czy Deweloperzy wprowadzać ulepszenia bez tworzenia PBI. Po zmianach z listopada 2020 nie ma miejsca na ustępstwa. To co się nie zmieniło to odpowiedzialność PO za priorytetyzację całej listy. W jaki sposób Właściciel Produktu może uszeregować elementy backlogu? Jakie są najczęściej stosowane metody priorytetyzacji? O tym poniżej.
Co może wpłynąć na priorytetyzację zadań przez Właściciela Produktu?
Lista czynników, które mogą wpłynąć na uszeregowanie PBI może być długo i często zależna nie tylko od skomplikowania, złożoności i wielkości produktu. Z mojego doświadczenia wynika, że najczęściej pojawiającymi się powodami są:
- Priorytety od użytkowników końcowych;
- Pilność uzyskania informacji zwrotnej;
- Koszt lub/i czasochłonność implementacji danego rozwiązania;
- Zależności pomiędzy poszczególnymi PBI;
- Zależności związane dostawcami zewnętrznymi;
- Rekomendacje pozostałych członków Zespołu Scrumowego;
- Oraz wiele wiele innych.
Jak widzimy wypisanie nawet kilku podstawowych czynników mających wpływ na uszeregowanie elementów Backlogu Produktu powoduje, że mamy całkiem sporą listę. Warto zadać sobie następujące pytanie: jak będąc jedyną osobę odpowiedzialną za priorytetyzację poradzić sobie z tak wieloma czynnikami? Z odpowiedzią przychodzą metody priorytetyzacji.
Metody priorytetyzacji, które najczęściej polecam
Technik czy metod priorytetyzacji jest dostępna cała gama. Są takie, które wybieram zdecydowanie częściej oraz te po które sięgam rzadziej. Od lat pracując jako Scrum Master przy wspieraniu PO w tym aspekcie upodobałam sobie kilka technik, które znajdziecie poniżej.
MoSCoW
Metoda ta używana jest przy współpracy z interesariuszami i pozwala ustalić wspólny poziom zrozumienia ważności poszczególnych wymagań. Żeby lepiej przedstawić co mam na myśli rozbije nazwę techniki na poszczególne składowe:
- M jak Must have to wymagania, które są krytyczne dla produktu do zrealizowania w określonych ramach czasowych jeżeli chcemy mówić o jego sukcesie. Inaczej mówiąc – jeżeli chociaż jedno z wymagań oznaczonych jako Must have nie będzie dostarczone to wtedy produkt odnosi porażkę.
- S jak Should have to wymagania, które są równie istotne, ale nie krytyczne dla sukcesu produktu. Bez nich produkt może istnieć.
- C jak Could have to wymagania pożądane, ale nie niezbędne dla istnienia produktu. Mogą usprawnić doświadczenia użytkownika końcowego, czy poprawić jego satysfakcję z produktu, najczęściej niewielkim kosztem developmentu. Zazwyczaj dodawane do produktu, gdy pozwala na to czas i budżet.
- W jak Won’t have to wymagania o najmniejszym znaczeniu, najmniej opłacalne z tytułu zwrotu inwestycji lub niepotrzebne na tym poziomie istnienia produktu.
Zalety:
- Prosta i szybka;
- Próg wejścia jest stosunkowo niski jeżeli chodzi o zrozumienie metody;
- Może być wykorzystywana do bardzo wielu wymagań;
- Pozwala znaleźć elementy najbardziej i najmniej istotne z punktu widzenia sukcesu projektu.
Wady:
- Niezbyt pomocna przy wielu elementach o tej samej randze ważności;
- Nie uwzględnia technicznego złożoności wymagań.*
*Rozwiązaniem na tą wadę jest wprowadzenie osi poziomej, której grot wskazuje stopień skomplikowania wymagania. Przez co uzyskujemy matrycę złożoności i ważności poszczególnych funkcjonalności produktu.
Business Value / Story Points Ratio
Technika, która polega na wykorzystaniu stosunku wartości biznesowej do wartości Story Pointów. Ma ona na celu wybranie tych elementów które są stosunkowo najłatwiejsze i najszybsze do wdrożenia, a jednocześnie najbardziej pożądane przez użytkownika.
Jako wartość biznesową, w tym przypadku, rozumiem numeryczną skalę przyporządkowaną przez klientów do konkretnych wymagań. Im wyższa wartość numeryczna tym ważniejsze wymaganie. Zwyczajowo przyjmuje 1 jako wartość minimalną, 10 jako najważniejszą. Dobrze znane Story Pointy przydzielane są na poziomie poszczególnych PBI i określają czasochłonność, złożoność i pracochłonność zadań. Idealnym przypadkiem do zastosowania tej techniki jest sytuacja, w której klient współpracuje z nami przy tworzeniu poszczególnych elementów Backlogu Produktu. Nie jest jednak niemożliwe użycie tych dwóch miar do określania tego co jest najważniejsze dla produktu w stosunku do skomplikowania wdrożenia poszczególnych wymagań.
| PBI | BV | SP | Ratio |
| #1 | 1 | 8 | 8 |
| #2 | 4 | 5 | 0.8 |
| #3 | 10 | 8 | 1.25 |
| #4 | 7 | 5 | 1.4 |
Na podstawie dostępności Deweloperów, danych liczbowych i tym podobnym Właściciel Produktu może podejmować w pełni świadome decyzje odnośnie kolejności następnych wdrożeń.
Zalety:
- Przejrzysta i szczegółowa;
- Opierająca się na danych liczbowych;
- Moim zdaniem technika ta idealnie się sprawdza w przypadku ścisłej współpracy z użytkownikami. Korzystanie z User Stories sprawdza się tutaj bardzo dobrze.
Wady:
- Czasochłonna;
- Wymaga dobrego zrozumienia tego co kryje się pod poszczególnym PBI przez użytkowników końcowych. Często wiąże się to z koniecznością pracy z User Stories;
- Technikę można zastosować dla dużych wymagań, jednak lepiej się sprawdza przy PBI.
Business Value / Urgent Matrix
To kolejna, z moim zdaniem, trzech najskuteczniejszych metod priorytetyzacji, która może być wykorzystywana przez Właściciela Produktu. Tym razem obok wartości biznesowej stoi czasochłonność wdrożenia danego wymagania. Priorytet jest iloczynem tych dwóch składowych. Należy oczywiście przyjąć pewne założenia, które będą pomagały określać czasochłonność i złożoność danego PBI. Nie jest to bowiem system określania godzin potrzebnych do zrealizowania zadań, a wartość numeryczna. Podobnie należy postępować w przypadku wartości biznesowej, dla której przyjmuje się również tutaj wartości od 1 do 5. Ważne, żeby wszyscy znali i zgadzali się na przyjęte założenia. Tak żeby dla każdego uczestnika procesu nadawania wartości biznesowej czy określania czasołonności cyfra 1 była tożsama. Matryca tych dwóch wartości wygląda następująco:
Michael Lant, autor metody priorytetyzacji, przyjął również pewne założenia zakresów ważności poszczególnych pól matrycy, co odzwierciedlają kolory, które widzicie na powyższym schemacie. Kolorem zielonym oznaczone są PBI, które mają niski priorytet i są traktowane jako tzw. Nice to have. Kolor żółty to zadania o umiarkowanej ważności, prawdopodobnie do wdrożenia w kolejnych 2 lub 3 sprintach. Ważne PBI, które trzeba wdrożyć w najbliższym sprincie oznaczone są na pomarańczowo. Krytyczne znajdują się na czerwonym polu, a ich wdrożenie powinno odbyć się najszybciej jak to możliwe.
Zalety:
- Gdy już wszyscy zaznajomieni są ze skalą nadawania wartości biznesowej oraz poziomu czasochłonności może okazać się, że to szybka metoda.
- Technika to może być stosowana zarówno do prioretyzowania dużych wymagań jak i poszczególnych PBI.
Wady:
- Czasochłonność jeżeli chodzi o próg wejścia;
- Problem z określeniem priorytetu wielu elementów Backlogu Produktu, które znajdują się w tym samym sektorze matrycy.
Podsumowanie
Technik jest cała masa więc naprawdę jest w czym wybierać, powyżej wskazałam, te które najczęściej polecam Właścicielom Produktów. Dobór metody priorytetyzacji, jest zależny od tego jakimi informacjami dysponujemy, jak złożony jest projekt i od tego co tak naprawdę chcemy uzyskać poza priorytetyzacją. Polecam poznawać nowe techniki, łączyć je z tymi dobrze znanymi i znajdować takie rozwiązanie, które pomoże zrozumieć nam ważność poszczególnych elementów backlogu w najbardziej efektywny sposób.
Sprawdź nasze ostatnie wpisy:
