Wielu Product Ownerów zaczyna pracę od tworzenia wymagań. W niektórych sytuacjach zakresy są im narzucane. Główna ich praca to opisywanie tychże wymagań, czyli występowanie w roli skryby.

Na jakiej podstawie są te zadania poukładane w Product Backlogu?

Niestety, często na podstawie „wydaje mi się”, „tak mi powiedziano”, „tego chcą moi stakeholderzy” i inne podobne odpowiedzi.

Jak zatem tworzyć wartościowe wymagania?

Start with a vision. Each Product Owner should be driven by vision and be able to inspire an organization and teams that developing a product. A product vision should be short, understandable, inspiring, and describing necessary information about the product.

Wizja produktu powinna być krótka, zrozumiała, inspirująca i obrazować podstawowe informacje co to za produkt, dla kogo, jaką potrzebę klienta spełnia i jaką ma przynieść wartość.

Jest wiele rodzajów pomocnych szablonów wizji. Ja lubię „elevator pitch”. Jest krótki (30 sec do 2 min), prosty i wystarczający, żeby przekazać wizję. Zachęcam też do eksperymentów z innymi szablonami.

Focus on a business strategy. 

Skup się na strategii biznesowej. Przy tworzeniu strategii biznesowej produktu warto zaprosić stakeholderów, zespoły i każdego, kto może wesprzeć. Tutaj również możesz podeprzeć się istniejącymi szablonami, jak Business Model Canvas, Value Proposition Canvas lub kilka innych do wyboru. Z pewnością trzeba pamiętać, żeby zawrzeć persony (do kogo kierujemy nasz produkt), zdefiniować wartość, dostępnych ludzi i zasoby, strukturę kosztów, możliwe źródła przychodów, co robi konkurencja (jeśli jest) oraz inne ważne informacje.

Dzięki temu będzie łatwiej podejmować decyzje biznesowe. Zachęcam, aby tworzenie strategii przeprowadzać w formie warsztatów. Nawet, jeśli produkt jest wewnętrzny (dla organizacji), również należy mieć świadomość, kto jest odbiorcą, jaki mamy budżet, jaka płynie wartość z niego.

Business goals. 

Cele biznesowe. Co chcemy osiągnąć? Jaki to ma wpływ na organizację? Jaki ma to wpływ na naszych klientów (persony)? Co się zmieni w ich zachowaniu? Czego potrzebujemy, żeby to osiągnąć? I dopiero tutaj w tym momencie możemy zacząć myśleć o wymaganiach (epics, features, stories, ogólnie możemy je nazwać „items”). Wymagania są wtórne w stosunku do celów i wartości. Wynikają z nich. Pomocny tutaj może być Impact Mapping lub inna technika.

Product Backlog. 

Product Backlog. Powinien być ułożony w kolejności uwzględniającej:

• Wartość
• Ryzyko
• Zależności
• Kiedy wchodzimy na rynek z funkcjonalnością (można też zwizualizować w formie roadmapy)
• Możliwe inne czynniki, ważne z punktu widzenia produktu i organizacji

Wymagania powinny zawierać:

• Spójność z celem (celami) biznesowym
• Spójność ze Strategią biznesową
• Spójność z Wizją produktu

Często w organizacjach Product Backlogi są poukładane zgodnie ze zakresem przedstawionym jakiś czas temu. Albo pod wpływem nacisków stakeholderów. Nieczęsto są aktualizowane pod względem wartości. Ba, rzadko kiedy używane jest pojęcie wartości. Najczęściej wyznawany jest kult dostarczania (więcej, prędzej), pytanie czy to, co zespoły dostarczają przynosi użytkownikom i organizacji wartość?

What’s next? 

Co dalej? Trzeba mierzyć wartość produktu – tę aktualną i możliwy do osiągnięcia potencjał. Podejmować na tej podstawie decyzje. W organizacjach często decyzje nie są podejmowane na bazie faktów. Oczekuje się predykcji, dokładnych planów, jednocześnie nie bierze się pod uwagę aktualnego stanu produktu. Brakuje przestrzeni i akceptacji na adaptację. Innymi słowy brakuje empirycznego podejścia.

So, what should be the Focus for the Product Owner? 

Jeszcze raz – na wartości, tej, która wypływa z wizji, potrzeb klienta i organizacji, zadowoleniu klienta/użytkownika, strategii biznesowej, zmierzonej wartości i potencjału. Poukładaniu Product Backloga zgodnie z powyższymi. Zastosowaniu empiryzmu.