Kończymy dziś trylogię opisującą role w Scrum, chociaż możemy też obiecać, że nie jest to ostatni post na ten temat. We wcześniejszych wpisach i na kanale Youtube opisaliśmy szczegółowo Scrum Mastera i Zespół Deweloperski. Na deser pozostał nam Product Owner. Wspomnieliśmy już o nim przy okazji odpowiedzi na pytanie o najważniejszą rolę scrumową, ale dopiero dziś opiszemy go w całej okazałości.
Kim jest Product Owner?
W polskim przekładzie Scrum Guide „Product Owner” został przetłumaczony jako „Właściciel Produktu„. Sugeruje to pewne odpowiedzialności związane z faktem „posiadania” backlogu. Przede wszystkim istotne jest, aby Product Ownerem była to jedna osoba. Pełnienie tej roli przez dwie osoby albo przez komitet osób spowoduje nieuchronne pojawienie się konfliktów, chociażby w kontekście priorytetyzacji elementów Backlogu.
Product Owner powinien być też osobą właściwie umocowaną w organizacji. Reprezentuje on grupy interesariuszy i klientów (osoby zainteresowane efektami pracy naszego projektu), ale to PO podejmuje ostateczną decyzję co do kolejności realizacji poszczególnych elementów Backlogu Produktu. Nie może wystąpić sytuacja, w której ktoś może zawetować decyzje PO. Wtedy mamy do czynienia z sytuacją opisaną powyżej – organizowaniem Backlogu Produktu przez grupę ludzi, którzy niekoniecznie muszą się ze sobą zgadzać.
Waga tego aspektu jest bardzo często pomijana. Tymczasem zasada „jeden zespół – jeden backlog – jeden Product Owner” jest niezwykle istotna do utrzymania skupienia uwagi na celu. Oczywiście jeden PO może zarządzać wieloma backlogami, a jeden backlog może być realizowany przez wiele zespołów, ale odwrotna relacja nie powinna nigdy mieć miejsca.
Zadania Właściciela Produktu
Założę się, że Product Owner kojarzy się Wam z Product Backlogiem. Słusznie, bo podstawowym zadaniem Product Ownera jest zarządzanie listą wymagań naszego projektu. Jest on przedstawicielem klienta i jego podstawowym zadaniem jest przekazywanie całemu Scrum Teamowi jasnych informacji na temat szczegółów stojących za każdym jednym elementem Backlogu.
Zadaniami Właściciela Produktu, zgodnie ze Scrum Guide, są również:
„porządkowanie elementów Backlogu produkt w taki sposób, aby osiągnąć założone cele i misje”
Product Owner zna założenia realizowanego projektu, a także potrzeby klienta (często lepiej niż sam klient). Zgodnie z tymi informacjami PO powinien priorytetyzować elementy Backlogu Produktu przesuwając na szczyt listy wymagań te, które pozwolą osiągnąć największe zadowolenie klienta przy zachowaniu zasad Minimum Viable Product.
„optymalizowanie wartości pracy wykonywanej przez Zespół Deweloperski”
Dobry PO nie pozwoli Zespołowi Deweloperskiemu na wykonanie „kawałka dobrej, nikomu niepotrzebnej roboty”. Nie pozwoli także na niepotrzebne upiększanie i dodawanie wodotrysków do funkcjonalności, która będzie używana raz w roku. Product Owner wie, że zespół będzie bardziej zmotywowany widząc, że to co wytwarza jest faktycznie używane i użyteczne dla klienta.
Właściciel Produktu i… Backlogu
To prawda, że większość zadań i obowiązków Product Ownera dotyczy backlogu. Ale to nie znaczy, że PO pracuje sam dla siebie. Po pierwsze, stara się on odgadnąć i wyprzedzić potrzeby klientów i interesariuszy. O wiele ważniejszy jest jednak drugi odbiorca backlogu – Zespół Deweloperski.
„zapewnianie, że Backlog Produktu jest dostępny, przejrzysty i jasny dla wszystkich, a także opisuje to, czym Zespół Scrumowy będzie się zajmował w dalszej kolejności”
W zakresie powyższego Właściciel Produktu dba o fizyczną formę listy wymagań dotyczącą naszego przedsięwzięcia. Ważne jest, aby lista ta była dostępna i transparentna dla wszystkich członków Scrum Team jak również dawała jasną odpowiedź na pytanie, co będzie realizowane w kolejnych iteracjach.
„zapewnianie, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu”
Zgodnie z zasadami, które powinny spełniać dobre User Stories, wymagania powinny być szacowalne. Oznacza to, że User Story powinno być na tyle jasne i zrozumiałe dla Zespołu Deweloperskiego, aby ten podczas planowania sprintu był w stanie świadomie oszacować jej pracochłonność. Osobą odpowiedzialną za właściwe przedstawienie wymagania jest właśnie Product Owner.
Co jeszcze robi Product Owner?
Jeżeli chodzi o codzienną pracę Product Ownera w Sprincie, to skupiała się będzie na dwóch aspektach. Z jednej strony będzie to komunikacja z interesariuszami w temacie bieżących i przyszłych wymagań, czyli inaczej mówiąc „maksymalizacja dostarczanej wartości”. Wiąże się to z wspominanym już zarządzaniem Backlogiem Produktu, a także wieloma spotkaniami i dyskusjami. Taka rola.
Drugi aspekt roli PO, który zabierał będzie najwięcej czasu to dostarczanie Zespołowi Dewloperskiemu informacji na temat bieżących i przyszłych wymagań. To oznacza zarówno udział w sesjach Product Backlog Refinement, jak i zwykłe, codzienne rozmowy na temat aktualnie realizowanych funkcjonalności. Bo Product Owner nie jest elementem żadnej hierarchii w Scrum. Razem z zespołem bierze on udział w zadowalaniu klienta. A to znaczy, że często w trakcie Sprintu PO będzie tłumaczył i przekazywał wymagania i oczekiwania interesariuszy.
Product Owner bierze również udział w wydarzeniach Scrum, na których wymagany jest udział całego Scrum Team. Mam tu na myśli Planowanie Sprintu (Sprint Planning), Przegląd Sprintu (Sprint Review) oraz Retrospektywy Sprintu (Sprint Retrospective). Warto podkreślić, że nie pojawia się na Daily Scrumie.
Jako osoba odpowiedzialna za spojrzenie całościowe, Product Owner zainteresowany jest prognozowaniem długoterminowym. Przynajmniej na Sprint Review aktualizuje on plany i spodziewane terminy ukończenia dużych funkcjonalności, często kryjących się pod nazwą Epic.
Product Owner, a pozostałe role scrumowe
Właściciel Produktu może wykonywać swoje obowiązki osobiście, bądź cedować je na Zespół Deweloperski i/lub Scrum Mastera. Miejmy jednak na uwadze, że pomimo możliwości przekazania części obowiązków innym osobom to on jest w dalszym ciągu odpowiedzialny za wygląd Backlogu Produktu. Oznacza to, że jakiekolwiek zmiany mające wpływ na Backlog Produktu powinny być z nim uzgadniane.
Scrum Master został w szczególny sposób wskazany do pomocy Właścicielowi Produktu. W zakresie obowiązków tego drugiego wpisane zostały między innymi dbanie o zrozumienie Backlogu Produktu przez Zespół Deweloperski. Scrum Master ma wspomóc Właściciela Produktu swoją wiedzą w zakresie technik efektywnego zarządzania listą wymagań, formułowania wymagań (np. w postaci User Stories) czy ich dekompozycji. Ma to na celu wsparcie Scrum Teamu w osiągnięciu celu i wizji projektu.
W skalowanych metodykach Agile wariantem Product Ownera są m.in. Area Product Owner i Proxy Product Owner, a także Tribe Leader. Wyodrębnienie tych ról jest próbą pogodzenia wielkości Backlogu i jego niepodzielnego właścicielstwa. Zasada „jeden zespół ma dokładnie jeden backlog, który jest zarządzany przez dokładnie jednego Product Ownera” powinna być spełniona w każdym przypadku.
Aby wspomóc Zespoły Scrumowe w szybkim i efektywnym podejmowaniu decyzji wspomniane warianty PO są „przedstawicielami” Właściciela Produktu w zespołach. Nie tylko odpowiadają oni za wyznaczoną część Backlogu Produktu. Mają też możliwość decydowania (za wiedzą Product Ownera) o kierunku prac w tej części, za którą są odpowiedzialni.
Product Owner jako niezbędne ogniwo Scrum
Jakiś czas temu, na naszym kanale #białko, próbowaliśmy znaleźć odpowiedź na pytanie czy rola Product Ownera może zostać zastąpiona przez inną. Odpowiedź może być tylko jedna: w żadnym wypadku! Obowiązki Właściciela Produktu są na tyle dookreślone, że nie ma możliwości ich „przerzuceniach” na inną rolę scrumową na projekcie.
Product Owner powinien też być osobą o pewnych cechach osobowościowych. Według mnie powinien być dobrym „sprzedawcą”. Konieczność budowy i zarządzania Backlogiem Produktu na podstawie wymagań interesariuszy to tylko jedna strona medalu. Druga to umiejętność negocjacji z „biznesem” zakresu prac czy przekonywania do „trudnych reworków”?
Scrum Guide milczy w temacie codziennych trudów Product Ownera, który musi przekonać zamawiającego do pracy iteracyjnej. A to znaczy, że nie tylko powinien on dobrze sprzedać ideę MVP, ale także unikać tworzenia rzeczy, które klient chce, ale których nie będzie używał. Dodajmy do tego próby upraszczania rozwiązań (pragmatyzm) i przekonywania interesariuszy do przesuwania budżetu z wodotrysków na zyskowne funkcjonalności i będziemy mieli bardziej kompletny obraz odpowiedzialności PO.
Tego zakresu obowiązków nie jest w stanie spełnić nikt inny. Potrzebujemy Product Ownera.
Jeżeli jesteś Product Ownerem bądź przymierzasz się do pełnienia tej roli, zapraszamy na nasze szkolenie Scrum dla Product Ownera oraz na warsztaty Wymagania w Projektach Agile.