W dzisiejszym wpisie skoncentrujemy się na najczęstszych błędach popełnianych przez Product Ownera. Podpowiemy też, jak przygotować się do sytuacji, w których te błędy najczęściej się pojawiają.
Błędy popełniane przez Product Ownera – omówione zagadnienia:
- Problemy na linii Product Owner – Klient
- Problemy na linii Product Owner – reszta Scrum Team
- Podumowanie
Problemy na linii Product Owner – Klient
Product Owner jest osobą, która personalnie odpowiada za niepowodzenia Scrum Team. Z racji swojej pozycji wykraczającej poza działania zespołu mówi się, że jest single wringable neck, czyli pojedynczym karkiem do skręcenia. Innymi słowy, to właśnie on najbardziej ucierpi w sytuacji, gdy praca Scrum Team nie idzie po myśli Klienta i inwestora. Jak zatem radzić sobie w problematycznych sytuacjach i chronić się przed najczęstszymi błędami?
Dla ułatwienia przedstawiliśmy problemy z klientem w tabelce. Pod nią znajdziecie szczegółowe omówienie każdego z problemów.
Błąd | Generowany problem | Sugestie rozwiązania |
---|---|---|
Nieumiejętność ustalania priorytetów | Niezoptymalizowany Backlog Produktu, rozmywanie się Celu Produktu | Słuchanie, pytanie, negocjowanie Celu Produktu z Klientem, uważne opracowanie wyników negocjacji |
Brak asertywności | Zbyt wiele zadań do wykonania przez Scrum Team | Myślenie realistyczne, wiedza i pamięć o możliwościach zespołu |
Niewystarczające kwalifikacje biznesowe | Ryzyko obniżenia wartości biznesowej Produktu wytworzonego przez Scrum Team | Nieustanne uczenie się i zdobywanie kompetencji biznesowych |
Nieumiejętność ustalania priorytetów
Błąd polegający na nieumiejętności ustalania priorytetów to zmora wielu Product Ownerów. Dlaczego ustalanie priorytetów zadań jest kluczową kompetencją? Ponieważ w momencie, gdy wszystko staje się tak samo ważne, znika z oczu Cel Produktu. Czyli zamierzony efekt działania Scrum Team.
Problem zaczyna się już podczas pierwszych rozmów z klientami dotyczących Celu Produktu. Klient chce bowiem zwykle, aby zrealizować wszystkie jego pomysły jak najszybciej i jak najtaniej. Zadaniem Product Ownera jest więc ustalenie listy priorytetów. Jego zadanie polega na stworzeniu listy jasnych i możliwych do zrealizowania oczekiwań uszeregowanych od najważniejszych do najmniej ważnych. A trzeba to zrobić na podstawie nieustrukturyzowanych oczekiwań klienta.
Problem z priorytetami najczęściej ma źródło w niezrozumieniu oczekiwań klienta. Pojawia się wraz z niemożliwością wydobycia z klienta informacji o realnym Celu Produktu. Czyli odpowiedzi na pytanie, na jakie potrzeby produkt ma odpowiadać.
Jak więc chronić się przed tym błędem? Po pierwsze – słuchać uważnie klienta. Po drugie, nauczyć się zadawać pytania dotyczące Celu i sposobów działania poszczególnych funkcjonalności produktu. Po trzecie – negocjować i ograniczać Cele do zrealizowania. A do tego potrzebna będzie asertywność.
Gdy Product Owner trzyma już w ręce listę zadań do wykonania, w ich prioretyzacji i opracowaniu mogą pomóc sprawdzone metody. Na przykład zastosowanie tak zwanej macierzy Eisenhowera służącej do ustalania priorytetów zadań według kryteriów ważności i pilności.
Brak asertywności Product Ownera
Problemem, który ściśle łączy się z nieumiejętnością prioretyzacji jest brak asertywności. Wtedy do problemu nieodpowiednio ustawionej kolejki zadań prowadzącej do realizacji Celu Produktu dochodzi problem ich nadmiernej ilości. Dlatego zdolność powiedzenia nie klientowi jest naprawdę kluczowa.

Asertywność powinna być oparta na trzech filarach:
- wiedzy o możliwościach zespołu,
- wiedzy o używanych i rozwijanych przez zespół rozwiązaniach,
- świadomości własnej roli i wartości opartej o miejsce w Scrum Team.
Dlatego jednym z najważniejszych sposobów zapobiegania problemom z asertywnością jest codzienna praca Product Ownera ze Scrum Team. Dzięki temu zbuduje on realistyczne przekonania dotyczące czasu i możliwości realizacji pomysłów Klienta.
Niewystarczające kwalifikacje biznesowe
Następnym błędem, który chcielibyśmy omówić jest brak odpowiednich kwalifikacji biznesowych. Mocnymi stronami tych Product Ownerów są zwykle kwalifikacje specjalistyczne. Ich kompetencje wiążą się ściślej z obszarem działania Zespołu Developerskiego, niż z biznesem. Brakuje zatem ugruntowanej, praktycznej wiedzy dotyczącej konkurencji, zasad działania rynku, a także finalnego odbiorcy produktu tworzonego przez Scrum Team.
Nie ma prostego remedium, które zaradziłoby temu problemowi. Szczególnie, że może on pojawiać się w bardzo specyficznych sytuacjach. Z pewnością jednak dobrym kierunkiem działania dla Product Ownera świadomego jego istnienia jest nieustanne uczenie się i zdobywanie doświadczenia i kompetencji biznesowych.
Problemy na linii Product Owner – reszta Scrum Team
Zdolność prioretyzacji zadań, asertywność Product Ownera oraz jego wysokie kwalifikacje biznesowe składają się na umiejętności służące do stworzenia wzorowego Backlogu Produktu, czyli długoterminowej podstawy działania Scrum Team. Jeśli Backlog nie został zarysowany spójnie i trafnie, problemy w relacji z klientem przeniosą się na relację Product Owner – pozostali członkowie Scrum Team. A co za tym idzie, wpłyną bezpośrednio na skuteczność działania Scrum Team. Jakie jeszcze pułapki czekają w relacjach z pozostałymi członkami Scrum Team?
Dla ułatwienia przedstawiliśmy problemy na linii Product Owner – Scrum Team w tabelce. Poniżej znajdziecie szczegółowe omówienie każdego z problemów.
Błąd | Generowany problem | Sugestie rozwiązania |
---|---|---|
Niewystarczająca charyzma | Zespół Developerski nie wykonuje zadań zawartych w Backlogu, zdanie Product Ownera jest podważane | Budowanie autorytetu opartego na kompetencjach miękkich i wiedzy |
Niewystarczająca kwalifikacje specjalistyczne | Niezrozumienie codziennego działania oraz możliwości Zespołu Developerskiego | Orientacja w specjalizacjach członków zespołu, a także zdobywanie wiedzy na temat obszaru działania Zespołu |
Niesamodzielność | Rozmywanie odpowiedzialności | Wzmocnienie autorytetu |
Niewystarczająca charyzma
W codziennej pracy Product Owner ma za zadanie koordynowanie wytycznych Klienta ze sposobem ich realizacji przez Zespół Developerski. Bez wątpienia wymaga to posiadania odpowiedniego autorytetu, posłuchu i charyzmy.
Problemu niewystarczającego autorytetu nie da się rozwiązać z dnia na dzień. Wymaga długotrwałej pracy nad kompetencjami miękkimi. A także zdobywania wiedzy na temat zakresu zadań i umiejętności pozostałych członków zespołu.
Niewystarczająca kwalifikacje specjalistyczne
Jak pisaliśmy w artykule odpowiadającym na pytanie Kim jest Product Owner?, rola Product Ownera nie jest rolą stricte techniczną. Jednak znajomość podstaw specjalistycznych umiejętności członków Zespołu Developerskiego może znacząco podbudować autorytet Product Ownera.
Niewystarczające kwalifikacje w obszarze działania zespołu mogą nie tylko generować problemy z charyzmą i autorytetem Product Ownera. Błąd polegający na braku zainteresowania tym, w czym specjalizują się członkowie Zespołu Developerskiego, oraz podstawami ich kompetencji może generować zabawne sytuacje, ale również sytuacje o katastrofalnych skutkach biznesowych i interpersonalnych.
Dlatego też, aby Scrum Team mógł dostarczać produkty najlepszej jakości, Product Owner musi dokładnie rozumieć ich istotę. Zdobycie odpowiednich kwalifikacji nie powinno być trudne biorąc pod uwagę, że Product Owner jest częścią zespołu złożonego z profesjonalistów. Mogą oni służyć nie tylko wyjaśnieniami, ale również podpowiedzieć, z jakich źródeł warto czerpać wiedzę na temat ich dziedziny.
Niesamodzielność
Produkt Owner musi potrafić samodzielnie podejmować decyzje. Oczywiście kluczową kwestią jest znajomość uwarunkowań Scrum Team, oraz nieustanne rozmowy z Zespołem Developerskim. Jednak to właśnie Product Owner odpowiada głową za skuteczność jego działania. Z tego powodu musi budować swój autorytet i brać odpowiedzialność za podejmowane decyzje. Ostatnie słowo dotyczące kierunku działania zespołu, prioretyzacji i akceptacji zadań należy właśnie do niego.

Podsumowanie
Rola Product Ownera nie należy do łatwych. Dlatego podejmując się jej warto przygotować się na problemy, na które na swej ścieżce napotkali inni.
Problemy w relacjach z Klientem zwykle mają swe źródło w braku asertywności, nieumiejętności stawiania priorytetów oraz niewystarczających kompetencji w dziedzinie biznesu.
Trudności pojawiające się podczas pracy z resztą Scrum Team mogą wypływać z braku samodzielności. Ich powodem może być też niewystarczająca charyzma osoby, która podjęła się tej roli, a także brak specjalistycznych kwalifikacji i niechęć – lub brak czasu – na poszerzanie wiedzy.
Sprawdź kolejny wpis z tej serii, tym razem dotyczący pracy Scrum Mastera.
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.
Przewodnik Scrum:
- Słowniczek podstawowych terminów Scrum
- Czym jest Scrum?
- Wartości Scruma
- Jak wdrożyć Scrum w swojej firmie?
- Scrum Team - czym jest i jak działa?
- Kim jest Product Owner?
- Kim jest Scrum Master?
- Najczęstsze błędy popełniane przez Product Ownera
- Cechy dobrego Scrum Mastera
- Najczęstsze błędy popełnianie przez Scrum Mastera
- Współpraca Scrum Mastera z Product Ownerem
- Jakie statystyki i metryki powinien śledzić Scrum Master?
- Zespół Developerski w Scrumie
- Najczęstsze błędy popełniane przez Developerów
- Artefakty Scruma
- Skalowanie Scruma
- Co to jest Backlog Sprintu?
- Co to jest Backlog Produktu?
- Czym są User Stories?
- INVEST, czyli jak stworzyć dobre User Story
- Najczęstsze błędy popełniane przy pisaniu User Story
- Kryteria Akceptacji User Story
- Estymacja i Story Points w Scrum
- Jak działa Planning Poker?
- Team Estimation Game jako alternatywa dla Planning Pokera
- Czym jest Przyrost w Scrum?
- Czym jest Sprint w Scrum?
- Wydarzenia w Scrum
- Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
- Co to jest wykres spalania (Burndown Chart)?
- Jak tworzyć i jak interpretować wykres spalania?
- Zalety i wady wykresu spalania
- Tablice Kanban w Scrum i Scrumban
- Prędkość Zespołu Deweloperskiego
- Daily Scrum
- Sprint Planning
- Sprint Review
- Co to jest Retrospekcja Sprintu?
- Częste błędy w czasie Retrospekcji
- Jak przeprowadzić pielęgnację backlogu produktu?
- Gdzie zdobyć wiedzę i doświadczenie w Scrum?