Jak mam uporządkować Product Backlog (PBL)? A bardziej przyziemnie – co jest ważniejsze: funkcjonalność A, czy B? Jak to wpłynie na mój produkt?Jak to wpłynie na postrzeganie mnie w roli Product Ownera? Pracując z Product Ownerami często spotykam sie z tym zagadnieniem. Czy to w rozmowach bezpośrednich, czy też obserwując Ownerów w codziennej pracy widzę, że uszeregowanie user stories czy też innych itemów w PBL stanowi problem, zwłaszcza na początku przygody z byciem Właścicielem produktu (Product Ownerem).
Jak można więc to zrobić? Postanowiłem zebrać materiał, bazując na rozmowach z Właścicielami produktów oraz opiniach mądrych tego agile’owego świata. Może zacznijmy od zdefiniowania czym jest Product Backlog (PBL)?
Najlepszą definicję, czym jest Product Backlog, znalazłem na blogu Romana Pichlera. Stanowi ona, że PBL jest listą pracy pozostającej do zrobienia, niezbędnej do wytworzenia produktu. Zawiera on idee, wymagania, błędy oraz dług techniczny w postaci zadań związanych np z refactoringiem kodu. Dobre praktyki mówią także o tym, że PBL powinien zawierać również wszelkie kwestie związane z User Experience (UX), visual design oraz wymagania niefunkcjonalne (stabilność, wydajność, etc).
Jeżeli mamy PBL “zasilony” wszystkim, co ma związek z wytwarzanym produktem, Product Owner (często przy wsparciu zespołu) powinien uporządkować/ spiorytetyzować “itemy”, innymi słowy ułożyć je w kolejności realizowania. Cytując Romana Pichlera, “porządkowanie wyznacza zespołowi kierunek i pomaga przeprowadzić sprawnie planning – itemy w PBL są nie tylko uporządkowane, ale również uszczegółowione względem ich pozycji/hierarchii w PBL”.
Pod pojęciem porządkowania Pichler sprytnie przemyca jeszcze jedno zagadnienie – ich wielkość i prawidłowe uszczegółowienie. Innymi słowy im wyżej item w PBL, tym ma większą ważność, tym bardziej jest “gotowy” do wzięcia przez zespół do Sprint Backlogu (SBL). Najlepiej tę ideę oddaje rysunek, który widzicie powyżej (jest to jeden ze slajdów ze szkolenia CSM, które kiedyś miałem okazję odbyć z Jeffem Sutherlandem).
Im wyżej w PBL, tym item jest mniejszy. A na idee równiez jest w PBL miejsce, ale na samym dole, widoczne jako coś, co jest daleko przed nami (ale zespół wie już, że będzie to realizował).
Skoro mamy już definicję Product Backlogu oraz porządkowania, wróćmy do naszego głównego zagadnienia – jak porządkować/ piorytetyzować? Główne kryteria, dalej podążając za Romanem Pichlerem, to:
1. Wartość bieznesowa
Wartość biznesowa jest najczęstszym kryterium priorytetyzacji. I jest to właściwe, ponieważ chcemy dostarczać najbardziej wartościowe rzeczy. Ale pytanie brzmi, co powoduje, że dany item ma tę “wartość”? Osobiście odpowiedzi bym poszukiwał w metodyce Customer Development, Lean Startup, albo po prostu podpatrując, jak robią to inni. Bardzo generalizując wymienione w linkach metodyki / podejścia – sprawdzajmy jak najszybciej, czy nasza idea / hipoteza ma w ogóle szansę powodzenia. Innymi słowy, może trudno jest oszacować wartość biznesową danej idei czy funkcjonalności – może trzeba ją ustalić empirycznie, robiąc wersję minimum (MVP) i dopiero wtedy podjąć decyzję, czy idziemy z tematem dalej, czy też zarzucamy pomysł.
2. Zależności
Zależności istnieją w każdym PBL. Czasami jest tak, że funkcjonalności zależą od siebie i muszą mieć odpowiednią kolejność z uwagi na wymagania biznesowe, a czasami nie da się ich zrealizować bez zachowania kolejności dyktowanej przez zależności techniczne. Czasami jest też tak, że nie da się zrealizować funkcjonalności niosącej dużą wartość bez zrealizowania wymagania niefunkcjonalnego (np. szybkości ładowania poszczególnych stron serwisu). Na pewno jest też tak, że zależności w pewien sposób wiążą nam ręce, dlatego też jako Product Owner powinieneś włożyć maksymalnie dużo wysiłku w to, aby te zależności zminimalizować. Tylko wtedy będziesz miał miejsce, aby układać PBL wg wartości biznesowej.
3. Możliwości wdrożenia
To jest bardzo ciekawy punkt. Niewiele osób w ogóle zwraca na to uwagę, ale przecież można spojrzeć na PBL w sposób uwzględniający realizację tych zadań, których wdrożenie jest najprostsze. Z jednej strony ktoś powie, że jako zespół agile’owy powinniśmy dążyć do sytuacji, kiedy problem z wdrożeniem nie powinien w ogóle istnieć. Zgoda. Ale jednak jeśli nadal istnieje? Bywa tak, że PO może zrobić sam wdrożenie uruchamiając jeden przycisk, i to w trakcie Sprint Review. Ale bywa też tak, ze niektóre funkcjonalności do wdrożenia wymagają rozbudowy bazy danych, zrobienia migracji danych, zaplanowania przerwy technologicznej. Z drugiej strony powinniśmy oczywiście dążyć do jak najczęstszych wdrożeń, bo tylko w ten sposób możemy sprawdzić prawdziwość naszych założeń. Tylko dzięki szybkim i częstym wdrożeniom oraz zaimplementowaniu i użyciu takich metryk jak np HEART możemy sprawdzić, czy nasza pożądana funkcjonalność ma odpowiednią wartość biznesową.
Innym wymiarem “wdrażalności” jest możliwość grupowania konkretnych wymagań we większe wdrożenia (release’y). Komponując takie większe wdrożenie, Product Owner musi wziąć pod uwagę fakt, czy od strony biznesowej i/lub technicznej dana paczka funkcjonalności będzie tworzyła jedność.
Przeglądając agile’owe blogi, natrafiłem na dwie inne frapujące pozycje. Pierwsza to prezentacja Mike Cohn’a. Interesujące w niej są dla mnie dwa zagadnienia. Pierwsze to “dylemat koła”, jak je autorsko nazwałem, czyli podejmowanie decyzji, czy chcę mieć najpierw przednie lewe koło zamontowane w samochodzie, czy może jednak prawe tylne. Jak byście woleli? Oczywiście, jest to dylemat bez sensu i powinniśmy tak budować PBL, aby nie było takich sytuacji. Wydaje mi się, że próbując zrobić walking skeleton możemy takie sytuacje ominąć. Drugim zagadnieniem w prezentacji Mike’a jest to, że dość mocno forsuje on priorytetyzację opartą o dane finansowe. Znajdziecie tam wzory na NPV czy IRR. Byłem dość mocno poruszony tymi slajdami, ponieważ Mike jest jednym z agile’owych guru, a podaje metody priorytetyzacji niewiele mające wspólnego z empiryzmem, a bardziej zakorzenione w tradycyjnym zarządzaniu projektami.
Drugą interesującą pozycją w sieci, która dotyczyła niniejszego tematu, jest “blog” Microsoftu, gdzie możecie znaleźć przyjemne dla oka tabelki – jako fan excela miałem z tego dużo przyjemności :). Ale tak na serio – jest to dla mnie anty-wzorzec. Dlaczego? Może i oparcie priorytetyzacji na wielu kryteriach naraz się sprawdza. Może jak mamy duży projekt pocięty na małe kawałki, to ustawienie ich sobie w kolejności jest pomocne, ale nie ma wiele wspólnego z budowaniem produktu, a bardziej ma związek z dowożeniem ustalonego z góry zakresu w ustalonym z góry budżecie i harmonogramie. Nie jest to dla mnie “życiowe” podejście do tematu.
Praktyka
I tutaj chciałem płynnie nawiązać do rozmów, jakie odbyłem z Product Ownerami, z którymi pracuję na co dzień. Jak wszelkie wyżej wymienione kryteria priorytetyzacji są właściwe, tak na zadane Właścicielom produktów pytanie, jak priorytetyzują PBL, usłyszałem, że jest to:
- autorytarna decyzja Product Ownera, bazująca na:
- odpowiedzi na pytanie, czy to się wpasowuje w moje cele?
- zależnościach od innych zadań (o czym wyżej pisałem),
- płci zgłaszającego (pół żartem – pół serio, ale na pewno to, że kogoś lubimy, lub nie, ma wpływ na kolejność, kiedy daną rzecz zrealizujemy),
- jakości produktu (biznesowa i techniczna – trochę się to łączy z w/w punktem “Możliwości wdrożenia”),
- realizacja strategii firmy,
- Product Owner w roli CEO firmy (punkt pewnie najbardziej zbliżony do w/w punktu “Wartość biznesowa”),
- decyzja grona stakeholderów (anty-wzorzec podważający kompetencje i decyzyjność PO),
- decyzja szefa (jw., ale na pewno zdarza się relatywnie często),
- zasada “trochę temu, trochę tamtemu” (strategia na przetrwanie).
Jak widzicie powyżej, możemy z jednej strony snuć świetlane wizje o Product Ownerze samodzielnie porządkującym backlog z wykorzystaniem wyników badań, bo przecież mamy na razie tylko hipotezę i chcemy sprawdzić czy jest sens dalej ją realizować. Ale z drugiej strony takie podejście jest pewnie właściwe dla małych firm, najczęściej startupów. A co, gdy mamy dużą firmę, inwestorów i musimy się politycznie ustawić? Wtedy pewnie dużo bardziej naturalnymi kryteriami priorytetyzacji będą te przytoczone przez realizujących na co dzień swoje obowiązki Właścicieli produktów.
A jak wy porządkujecie swoje backlogi? Podzielcie się dobrymi praktykami, przemyśleniami.
*) Kiedyś „porządkowanie” nazywało się „priorytetyzacja”. Traktuje w tym wpisie oba pojęcia zamiennie, choć oczywiście porządkowanie jest trochę szerszym pojęciem.
PS. W grudniu 2017 roku ukazał się na naszych łamach nowy wpis, rozwijający kwestię priorytetyzacji o sposoby określania wartości biznesowej. Zapraszam do przeczytania.