Jak porządkować Product Backlog? — część I

Product Backlog (Rejestr Produktu jeśli wolisz po polsku) powinien być uporządkowany (ang. ordered). Każdy element Rejestru Produktu (ang. Product Backlog Item, PBI) posiada nadany, określony porządek (ang. order) na liście. Kilka lat temu ten zapis w Scrum Guide brzmiał inaczej. Wtedy pisaliśmy, że Product Backlog to spriorytetyzowana (ułożona według priorytetów) lista. Czy zmiana jednego słowa dużo zmieniła? Jeśli nie priorytet, to według czego określać porządek? Ze Scrum Guide wiemy tylko tyle, że Product Owner jest odpowiedzialny za ustalenie porządku Product Backlogu, a Zespół Deweloperski bierze zawsze elementy z góry listy.

Priorytet

Wiemy, że priorytet może być wysoki lub niski. Ale co to jest priorytet? Co znaczy, że coś ma jakiś priorytet? Z definicji priorytet oznacza po prostu pierwszeństwo. Z zasady jedna rzecz w grupie powinna mieć priorytet. Skąd Product Owner wie co ma priorytet, a co nie ma? Prawdopodobnie spyta o to interesariuszy. Może też poszukać informacji u klientów lub użytkowników.

A co zazwyczaj usłyszymy jak pytamy biznes o priorytety? Niestety zazwyczaj usłyszymy, że większość pozycji na liście ma priorytet. Można próbować określić priorytet na pewnej skali, na przykład od 1 do 5. Można też wprowadzić MoSCow, czyli Must have, Should have, Could have, Won’t have. Ale dosyć szybko okazuje się, że wiele rzeczy ma priorytet 1, albo nie ma żadnego elementu w kategorii Won’t have. Przecież Zespól Developerski nie może zajmować się tymi wszystkimi elementami na raz.

Oczywiście są różne techniki priorytetyzacji, z których warto skorzystać:

• priorytety finansowe
• model Kano
• 100 points
• peer consensus
• thirty five
• Business Value Poker
• Monopoly Money
• Relatywne Wagi
• Theme Scoring
• Theme Screening
• Model RICE

Jednak niekoniecznie budowanie produktu można realizować skupiając się tylko na rzeczach z wysokim priorytetem, a nawet zaczynając od nich. Zatem priorytet to tylko jedna ze zmiennych we wzorze na uporzadkowanie listy. Potrzebujemy wiedzieć trochę więcej, żeby uporządkować Product Backlog.

Wartość

Główną rolą Product Ownera, czyli Właściciela Produktu jest generowanie jak największej wartości poprzez odpowiednie budowanie produktu. Zatem skupmy się najpierw na najbardziej wartościowych elementach listy. Dla wielu osób niespodzianką jest to, że wartość każdego elementu powinna być określona. Zaraz obok opisu, porządku, oszacowania wielkości wartość jest obowiązkową właściwością każdego elementy Backlogu Produktu.

Widziałem już wiele Product Backlogów i niestety zazwyczaj wartość nie jest określona, a to jest duży problem. Możesz pomyśleć sobie, ale jak ja mam znać z góry wartość elementu i wiedzieć ile na nim zarobię? Może potrzebuję kilku, żeby w ogóle zacząć zarabiać? Nie chodzi o dokonanie magicznych obliczeń w Excelu. Tak samo jak wymagamy od Zespołu Developerskiego, żeby oszacował wielkość elementów przed ich wykonaniem, Product Owner może po prostu oszacować ich wartość. Wystarczy, żeby wiedział, które z nich mają większą wartość, a które mniejszą. Może skorzystać ze skali wartości podobnej do tej w Planning Poker.

Może też wybrać sobie skalę podobną do koszulek (T‑Shirt sizing), ale opartą na przykład o metale szlachetne. Czy ten element ma dla mnie wartość taką jak platyna? A może złoto? Srebro? Miedź? Zestawienie wartości z wielkością elementu ( a tym samym kosztem wykonania danego PBI) daje dobrą wskazówkę co do porządku na Product Backlog. Co wolisz zaimplementować? Złoto za 30 Story Pointów czy Żelazo za 30 Story Pointów?

I znowu niekoniecznie warto i możliwe jest budowanie elementów jedynie zgodnie z szacowaną wartością. Potrzebujemy znać jeszcze inne właściwości elementów Backlogu Produktu, żeby go dobrze ułożyć.

Ryzyko

Oprócz szybkiego dostarczania wartości w Agile chcemy przeprowadzać eksperymenty, żeby uczyć się. Często eksperymenty mają na celu minimalizację ryzyka. Chcemy jak najszybciej sprawdzić niewiadome elementy, podjąć decyzje.

Czasem musimy spełnić wymagania regulatora. Może z naszego punktu widzenia coś nie opłaca się budować pewnej funkcjonalności, ale może się zdarzyć, że regulator tego od nas wymaga. Jeżeli nie zbudujemy pewnej funkcjonalności, to KNF nałoży na mnie kilka milionów kary. To brzmi jak dobry powód, żeby jednak zrealizować taką funkcjonalność. Czasem ryzyko wygra z wartością. Wystarczy spojrzeć ile firm poświęca teraz środki na implementację RODO.

Czy to wszystkie zmienne, które Product Owner musi brać pod uwagę? Na pewno nie. Więcej w kolejnej części artykułu.