Ten post jest częścią cyklu Pierwsze Dni Scrum.
Jeśli zespół jest sercem Scrum a sprinty są rytmem, w jakim ono bije to elementy backlogu są krwią, którą to serce pompuje.
… a za Backlog w pełni odpowiedzialny jest Właściciel Produktu.
Jego rola jest najbardziej odpowiedzialną i zarazam najbardziej niedocenianą rolą w Scrum. Według współtwórcy Scrum Jeffa Sutherlanda, niskiej jakości backlog może łatwo doprowadzić do obcięcia tempa zespołu o połowę. Przyjmijmy oszczędnie, że mamy zespół, który kosztuje firmę coś w okolicach 50 tys. zł miesięcznie. Ile warto zainwestować, żeby upewnić się, że zespół pracuje nad tym, co rzeczywiście ma największe przełożenie na biznes? Ile nas będzie kosztowała walka ze źle podzielonym, niejasnym, nietrafnym backlogiem? Zgodnie ze znaną zasadą Garbage In, Garbage Out nawet świetny zespół nie wyprodukuje nic wartościowego na bazie słabego backlogu. Dobry backlog to też podstawa pomiaru i adaptacji – musimy dobrze rozumieć co i po co budujemy, żeby móc skutecznie śledzić postępy i właściwie reagować na nowe informacje.
Scrum Guide
Definicja reguł Scrum – Scrum Guide – mówi, że: “Właściciel Produktu (ang. Product Owner) jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.” oraz “Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.” Dodaje też: “Aby Właściciel Produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje.”.
Oznacza to, że PO musi łączyć głęboką wiedzę dziedzinową ze zrozumieniem technologii stosowanej przez zespół, by móc skutecznie wyjaśniać kontekst biznesowy pracy zespołu i zarazić członków zespołu empatią dla odbiorców systemu i entuzjazmem dla rozwiązania ich problemów. Jak podkreśla Scrum Guide musi też posiadać odpowiednią dozę autorytetu wobec innych jednostek w organizacji.
Wszystko to oznacza, że Właścicielem Produktu powinna być najwyżej postawioną osobą, która jest dostępna dla zespołu. W relacji Klient-Dostawca najlepiej, gdyby był nim ktoś po stronie Klienta. Stoi to jednak w sprzeczności z potrzebą zainwestowania dużej ilości czasu i energii w “inżynierię wymagań” przez regularną pielnęgnację formy i treści poszczególnych historyjek.
Dlatego tak ważne jest odpowiednie uformowanie relacji między PO a zespołem w taki sposób, by zespół mógł wesprzeć Właściciela Produktu w porządkowaniu backlogu z zachowaniem pełnej głębi jego biznesowej wizji.
Rola PO według Henrika Kniberga
Henrik Kniberg – znany Agile Coach ze Szwecji, obecnie pracujący w Spotify, nagrał ostatnio bardzo dobry filmik trafnie podsumowujący rolę PO.
Wybrane spostrzeżenia Henrika z jego prezentacji:
- Głównym zadaniem PO jest określenie “Jaki problem powinniśmy rozwiązać i dla kogo?”.
- Największym wyzwaniem jest zarządzanie oczekiwaniami odbiorców poprzez umiejętną selekcję pomysłów i życzeń umieszczanych w backlogu.
- O ile misją PO jest maksymalizacja wartości pracy zespołu to wartość ta nie zawsze ma postać funkcjonalności dostarczanej klientom – często wartością jest wiedza pozwalająca zminimalizować ryzyko:
- biznesowe (że produkt nie będzie naprawdę przydatny),
- osobowe (że nasz zespół nie będzie w stanie zbudować produktu),
- techniczne (że wybrana technologia nie sprosta wyzwaniu),
- oraz budżetowo/harmonogoramowe (że nie zdążymy zbudować produktu na czas i poniesiemy dodatkowe koszty).
To tylko wybrane spostrzeżenia, cały filmik trwa tylko 15 minut i jest wart obejrzenia w całości:
[youtube http://www.youtube.com/watch?v=502ILHjX9EE]
Lean Startup
Marek Kirejczyk, współzałożyciel firmy Aenima i grupy Agile Warsaw nazwał go zaginionym podręcznikiem Product Ownera. Główną tezą Lean Startup (oraz wcześniejszej metodologii Customer Development, z której czerpie inspirację) jest, że tworząc nowy produkt naszym pierwszym zadaniem powinno być nie tyle zbudowanie jak największej liczby funkcjonalności, co raczej zweryfikowanie założeń biznesowych stojących za pomysłem na produkt.
W kontekście produktów na rynek masowy główne pytanie brzmi: Czy nasz model biznesowy jest powtarzalny i (opłacalnie) skalowalny? W kontekście projektów dla pojedyńczego odbiorcy pytanie sprowadza się do: Czy na pewno rozumiemy prawdziwe potrzeby Klienta?
Lean Startup dostarcza też narzędzi do poszukiwania odpowiedzi na te pytania. Wśród nich wyróżnia pętlę Build-Measure-Learn, czyli znaną pętlę tworzenia gotowego produtku po każdym sprincie rozbudowaną o rygorystyczny pomiar skuteczności produktu w osiąganiu założonych celów (przyciągania uwagi klientów, konwersji, utrzymania, …). Lean Startup nazywa wiedzę zdobytą w ten sposób wiedzą zweryfikowaną (Validated Learning) a wśród stosowanych miar wyróżnia tzw. Actionable Metrics, na podstawie których można podejmować trafne decyzje co do dalszych działań oraz Vanity Metrics, które służą co najwyżej do połechtania ego twórców.
Dowiedz się więcej na stronie ruchu Lean Startup.
Zadanie dla Was:
Dla Właściciela Produktu: Co jest najważniejsze dla naszych Klientów? Wypisz trzy najważniejsze wartości i omów je z zespołem – jak możecie dostarczyć jeszcze więcej tej wartości tym samym, albo mniejszym nakładem pracy?
Dla zespołu: Jak możecie pomóc PO przygotowywać lepszy backlog? Bardziej przejrzysty i zrozumialy? Pozwalający łatwiej śledzić postępy prac? Pozwalający szybciej dostarczyć realną wartość?
