Porządkowanie* backlogu- jak to zrobić?

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?10248755515_8cf2f53abc_o

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).

Product Backlog wg Sutherlanda

Dobry Product Backlog wg Jeffa Sutherlanda

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.

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.

Komentarze do wpisu: “Porządkowanie* backlogu- jak to zrobić?

  1. U mnie pierwszeństwo mają rzeczy na które wiem, że istnieje realne zapotrzebowanie i będą używane. Te rzeczy segreguje wg. czasochłonnośći/kosztu, wartości i rzecz jasna ewentualnych zależności.
    Dalej są rzeczy które podrzucają inni (nie do końca Ci, którzy finalnie będą produktu używać :)).

  2. Porządkujac backlog często właśnie można wpaść w pułapkę „pójścia na ilość”. Drobne krótkie storyjki na górę, bo szybko można je wdrożyc, a te większe czasochłonne, choć strategiczne spychamy na dół. Pytanie czy to naprawdę rozwija produkt, czy tylko go trochę ulepsza bez odkrywania nowych potencjałow.

  3. Pracowałem przez jakiś czas w roli PO w zespole, który poprawiał jakość złożonych systemów odziedziczonych.

    Porządkując nasz backlog moim głównym kryterium było „cost of delay” – co się stanie jeżeli opóźnimy realizację danego zadania. Było to chyba jedyne możliwe kryterium przy porównywaniu bardzo różnych zadań typu:
    – dopiszemy testy integracyjne w module A
    – dodamy sprawdzanie danych wejściowych w module B
    – stworzymy skrypt do partycjonowania tabel w systemie C

    Systemy były różne, zadania były różne, zatem najlepszą podstawą do porównań było zadanie sobie pytania „co będzie jeżeli tego nie zrobimy”. Co się stanie jeżeli nie będzie testów, jakie będą konsekwencje działania bez kontroli danych wejściowych, co się stanie jeżeli nie będzie partycjonowania.

    Nie mieliśmy żadnych wzorów / wartości, porównywanie odbywało się w głowie. Ale było to wystarczające dla naszych potrzeb.

    • Dawid Lewandowicz

      Bardzo dziękuje Staszek za komentarz. Pokazujesz kolejną forme priorytetyzacji, cost of delay, której ja nie wymieniłem. Zagdzam sie z tym podejściem i czasami warto sie zastanowić ile stracimy (zamiast zarobimy) jeżeli danej funkcjonalnosci nie dostarczymy na produkcję/ na czas.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x