Product Owner, Product Backlog, Przyrost może być tylko jeden

Kto by pomyślał, że słynny cytat z filmu Nieśmiertelny (ang. Highlander) dotyczy Product Ownera w Scrum. Jest jeden Produkt, który dostarcza Zespół Developerski, lub kilka Zespołów Developerskich. Zarządza tym Produktem jedna osoba, która jest jego właścicielem, stąd nazwa Product Owner (Właściciel Produktu). Product Owner utrzymuje uporządkowaną listę rzeczy do zrobienia w tym Produkcie, Product Backlog. Przynajmniej raz w Sprincie powinien zostać dostarczony jeden, przetestowany, użyteczny, potencjalnie gotowy do wdrożenia (zgodny z Definition of Done) Przyrost Produktu.
Wszystkie te zasady mają bardzo konkretny sens i przeznaczenie.

Dlaczego to jest jedna konkretna osoba a nie komitet? W każdej organizacji jest tak, że wielu interesariuszy Produktu będzie miało swoje potrzeby i oczekiwania co do Produktu i ktoś musi arbitralnie podejmować decyzje. Zespół Developerski pracuje bardzo szybko i często może odkrywać w swojej pracy rzeczy, o które wcześniej nie pytali. Dlatego potrzebny jest jeden punkt kontaktu, żeby zdobyć informacje. Product Owner oczywiście nie musi znać wszystkich szczegółów, ale będzie potrafił wskazać właściwą osobę. Czekanie na decyzje płynące z komitetów sterujących powoduje przestoje albo pracę na mniej wartościowych elementach.

Próba (a widziałem to w praktyce) posiadania więcej niż jednego Product Ownera kończy się zawsze konfliktami i walką o “zasoby”. Ciężko też jest utrzymać spójność Produktu. Może się okazać, że bardziej żółte ikony albo zaokrąglone rogi staną się tak samo ważne jak umożliwienie zawarcia umowy z klientem. Bo przecież ten drugi Product Owner też musi coś dostać. Planowanie takich Sprintów zwykle skutkuje kilkoma Celami Sprintów, a Sprint kończy się dostarczeniam niespójnych elementów Product Backlog. łatwo sobie wyobrazić, że Sprint review wygląda wtedy jak dziwny status i tak w sumie nie wiadomo co osiągnęliśmy. A do kogo iść jeśli okaże się, że trzeba renegocjować zakres Sprintu, bo wszystko się nie zmieści?

Jeden Product Owner łatwiej wyznaczy Cel Sprintu i spójny z nim zakres, dzięki czemu Zespół Developerski łatwiej skupi się na dostarczeniu konkretnych efektów.

Product Owner jest odpowiedzialny w sensie accountability, więc nie musi samodzielnie wykonywać swojej pracy w kontekście pracy z Product Backlog, ale nadal pozostaje odpowiedzialny za zawartość i porządek Product Backlog.

Żeby Product Owner mógł prawidłowo działać w Scrum musi być odpowiednio umocowany w organizacji, a dokładniej odpowiedzialność za produkt i budżet powinna być do niego/niej oddelegowana w pełni.

Podsumowując, jeden Product Owner daje nam szybsze podejmowanie decyzji co do zakresu, szybsze zdobywanie informacji. W sumie w ten sposób upraszczamy podejmowanie decyzji i komunikację.

Posiadanie jednej, jednowymiarowej listy upraszcza określanie co jest najbardziej wartościowe. Jeden Product Backlog to również wymuszenie podejmowania decyzji co do każdego elementu, ponieważ dwa elementy nie mogą być równie ważne, co często zdarza się kiedy rozmawiamy wyłącznie o priorytetach.

Jeden Product Backlog stanowi jedynie miejsce pobierania pracy. Zespół Developerski wie jakie są plany na przyszłość i co wymaga pielęgnacji. Wiadomo ile elementów zostało już zrobione i łatwo podsumować co jeszcze mamy do zrobienia. Szukanie informacji też jest proste, bo zawsze wystarczy poszukać w jednym miejscu.

Łatwo można podsumować sumę oszacowań i sprawdzić ile jeszcze Sprintów, a tym samym budżetu potrzebujemy, żeby zrealizować plany.  Jeśli na Product Backlog odłożymy Velocity Zespołu, to w prosty sposób uzyskamy roadmapę rozwoju produktu.

Dowolne zmiany na jednym Product Backlog nie umkną osobom zainteresowanym.

Podsumowując, jeden Product Backlog zapewnia przejrzystość planów, przejrzystość informacji umożliwia sprawdzanie i dostosowywanie.