Priorytet, to nie znaczy wartość. A wartość niekoniecznie znaczy kolejność. Niestety, nie zawsze jest to dla Product Ownerów jasne, szczególnie, że gdzieś po drodze miesza nam się jeszcze kolejność…
Priorytet, czyli co?
Dużo miejsca na naszym blogu poświęcamy ostatnio zagadnieniom związanym z Product Ownerem. Wpis „Jestem Product Ownerem” czy „Rejestr produktu, a wartość jego elementów” to tylko dwa z wielu przykładów. Dziś z kolei zgłębiamy temat organizacji Product Backlogu i próbujemy odpowiedzieć na pytanie: Co powinno być wiążące dla Product Ownera – priorytet czy wartość biznesowa?
Poszczególne elementy Backlogu Produktu nie są ułożone przypadkowo. Ich kolejność wyznacza najważniejsze na daną chwilę elementy do realizacji podczas najbliższego Sprintu. Im dany element listy wymagań ważniejszy, tym wyżej znajduje się na liście wymagań. A przynajmniej powinien, gdy mówimy o wykorzystaniu metodyki Scrum.
Technik, które pomóc nam mogą w określeniu kolejności jest wiele. Warto przypomnieć choćby o metodzie MoSCoW, którą jakiś czas temu opisywaliśmy na naszym zwinnym blogu. Możemy skorzystać z dowolnej metody, możemy nie wykorzystywać żadnej i działać „ekspercko”.
Każdy proces priorytetyzacji ma jednak jedną cechę wspólną. Ma pomóc w podjęciu decyzji, co jest niezbędne do realizacji w pierwszej kolejności.
Wartość biznesowa
Wartość biznesowa to wartość danego elementu z punktu widzenia nasze klienta podczas rozmów o wymaganiach. Mówiąc o wartości nie zawsze mamy na myśli liczbę, która jest wyrażona w pieniądzach. Często bardzo trudno jest przewidzieć konkretne wielkości finansowe, możliwe do osiągnięcia realizując dane wymaganie. Czasem taką wartość da się odnieść wprost do kar, których potencjalnie unikniemy realizując dane User Story. Wtedy możemy naszą korzyść określić dość precyzyjnie.
A jeśli nie pieniądze, to co? Tu na myśl przychodzą wówczas wszystkie argumenty przedstawiane nam przez biznes, które świadczą o absolutnej niezbędności danej zmiany w produkcie. Im goręcej mówi o tym interesariusz, im większa dyskusja wynika z omawianych zmian, tym możemy mieć pewność, że jest to ważniejsze dla naszych decydentów.
Korelacja kolejności i wartości biznesowej
Czy istnieje zatem korelacja między dwiema opisywanymi powyżej zmiennymi? Na tak postawione pytanie odpowiedzieć można dwojako.
Po pierwsze – jak najbardziej tak. Poszczególne elementy backlogu powinny być posortowane według istotności dla naszego klienta. Oznacza to, że wartość biznesowa, którą określił on w kontekście każdego z tych elementów powinna wyznaczać kolejność realizacji prac. A co jeśli klient się myli? Co jeśli wskazana przez niego kolejność nie jest prawidłowa z punktu widzenia maksymalizowania wartości całego produktu lub jego interesów długoterminowych?
Odpowiedź na pytanie o wzajemną korelację terminów będzie dla odmiany brzmiała „nie”. Nie ma wzajemnych relacji między kolejnością PBI (Elementów Backlogu Produktu), a ich wartością biznesową. Dość łatwo jestem sobie w stanie wyobrazić sytuację, w której interesariusz przekonany do własnej wizji rozwoju produktu nie da się przekonać do innego sposobu czy innego terminu realizacji danej potrzeby. W takiej sytuacji pozostaje nam ostatnia deska ratunku.
W naszym Scrum Team znajduje się osoba, która jest odpowiedzialna za listę wymagań. Co więcej, będąc osobą umocowaną w organizacji ma możliwość podejmowania dowolnych decyzji w zakresie kolejności PBI-ów. To oczywiście Product Owner.
Priorytet czy wartość biznesowa dla PBI?
W pierwszej z przedstawionych powyżej sytuacji, PO nie będzie miał nic do roboty. Ułoży wymagania na liście zgodnie z ich wartością biznesową zapewniając, że te, które są najważniejsze dla interesariuszy znajdują się na szczycie. I nimi w pierwszej kolejności zajmie się Zespół Deweloperski.
W drugim z opisywanych przypadków, PO będąc maksymalizatorem wartości podejmie wyzwanie. Ułoży elementy Backlogu Produktu inaczej, niż chce tego biznes. Dlaczego tak zrobi? Bo może. Świadomy PO ułoży elementy backlogu w taki sposób, aby zagwarantować maksymalne wykorzystanie zasobów przy jednoczesnej maksymalizacji korzyści płynących z ich realizacji.
Ale czy nie będzie musiał się z tego tłumaczyć? Najpewniej tak. Zawsze jednak powtarzamy, że mało jest ludzi, którzy widząc, że robiąc coś inaczej osiągamy lepsze wyniki nadal będą nas zmuszali do podejmowania mniej korzystnych rozwiązań. To przecież wbrew interesowi firmy, a jedynie zgodnie z czyimś ego.
Dlatego też praca Product Ownera to nie jedynie zbieranie wymagań, wartości biznesowej i ich priorytetyzacja. To ciągła współpraca z partnerem w postaci interesariuszy projektu nad takim ułożeniem PBI, aby satysfakcjonowały one każdą ze stron.
Wystarczy (tylko i aż) rozmawiać.
