Dlaczego priorytetyzacja?
W Przewodniku po Scrumie jest napisane, że każdy element Product Backlog powinien mieć określony porządek (ang. order). Kiedyś w Scrum Guide było napisane, że Product Backlog to spriorytetyzowana lista. A teraz nagle narzędzia priorytetyzacji zamiast określania porządku? Jak to rozumieć?
Przede wszystkim zmiana słowa priorytet na porządek w kontekście elementu Product Backlogu ma zwrócić uwagę na to, że porządek, w jakim będą realizowane poszczególne elementy, wynika z wielu innych czynników oprócz priorytetu. Co brać pod uwagę, określając porządek w Backlogu, to temat na post sam w sobie, ale wymienię przynajmniej najczęściej spotykane czynniki. Oprócz priorytetu mamy przede wszystkim zależności takich typów: technologiczne, biznesowe, spójności wydania, zewnętrzne (te są najgorsze). Do tego dochodzi nam wartość biznesowa i ryzyko, o ile nie odzwierciedlają tego priorytety.
Co oznacza priorytet?
Priorytet powinien odpowiadać na pytanie „Na ile jest to ważne”? W praktyce zbyt często spotyka się metodę priorytetyzacji HIPPO (Highest Paid Person Opinion) i metodę mokrego palca. Kiedy po prostu pójdziemy do biznesu i spytamy, co jest ważne, to dowiemy się, że wszystko albo prawie wszystko. Z takim oszacowaniem priorytetu nie da się pracować.
Ktoś może powiedzieć, że porównywanie dwóch funkcjonalności to, jak to Amerykanie mówią, porównywanie jabłek i pomarańczy. A jednak w życiu codziennie porównujemy różne rzeczy i wiemy, czy kupić pomarańcze, czy jabłka. Najważniejsze jest porównywać je względem tych samych, ustalonych kryteriów. Dziękuję Łukaszowi Szóstkowi za przypomnienie mi tej metafory i bodziec do napisania posta, który długo leżał w backlogu bloga.
Priorytety powinny wynikać z celów biznesowych, które chcemy zrealizować, budując produkt. W dużych organizacjach cele biznesowe powinny być zgodne ze strategią przedsiębiorstwa. Żeby dobrze zidentyfikować cele, trzeba najpierw dobrze zidentyfikować interesariuszy. Jako interesariuszy rozumiemy przynajmniej takie grupy jak sponsorzy, użytkownicy, biznes, regulator.
Dlaczego priorytetyzacja Tematów?
Temat to wysokopoziomowy element Backlogu Produktu. Można powiedzieć, że jest to funkcjonalność produktu. Temat zawiera w sobie kilka Epików, a te zawierają User Story. Czyli zakładamy, że struktura Product Backlogu wygląda tak: Temat -> Epik -> User Story. Ustalenie priorytetów ma największy sens z punktu widzenia budowania strategii wydań na poziomie konkretnych funkcjonalności, czyli Tematów. Wtedy odpowiadamy sobie też na pytanie: „Co w ogóle powinno być w produkcie?”, czyli określamy najpierw zakres, a później strategię dostarczania funkcjonalności.
Porównywanie Epików między sobą też jest możliwe. Trzeba pamiętać tylko, że Epików będzie znacznie więcej niż Tematów. Porównywanie Tematów z Epikami, a tym bardziej User Story, nie ma sensu, bo Temat zawsze wygra ze względu na skalę. Po wyborze tematów można się zastanowić, które Epiki musimy zrealizować, a w ramach każdego z nich, które User Story.
Na czym polega technika Theme Screening?
Technika Theme Screening, którą nazwałem w książce Scrum i nie tylko Selekcją Tematów, polega na relatywnym porównaniu Tematów w odniesieniu do Tematu bazowego w kontekście wybranych kryteriów. Najlepiej, żeby kryteria oznaczały cele biznesowe. Temat bazowy otrzymuje we wszystkich kategoriach wartość 0. Pozostałe tematy są porównywane z Tematem bazowym w kolejnych kategoriach.
Jeżeli porównywany temat bardziej wpływa na osiągnięcie celu niż Temat bazowy, to w komórce wpisujemy +. Jeżeli porównywany temat mniej wpływa na osiągnięcie celu niż Temat bazowy, to w komórce wpisujemy -. Jeżeli porównywany temat wpływa na osiągnięcie celu tak samo jak Temat bazowy, to w komórce wpisujemy 0. Na końcu sumujemy kolumny, przyjmując za — wartość ‑1, a za plus +1. W ten sposób zobaczymy, które tematy zebrały najwięcej punktów.
Przykład Theme Screening wygląda tak:
Przykład Theme Screening
Na co zwracać uwagę w technice Theme Screening?
Wynik użycia narzędzia będzie tak dobry, jak jakość danych do niego wprowadzonych. Jeśli będą to zmyślone dane, to wyjdzie nam dziwny wynik. Jeśli użyjemy narzędzia do udowodnienia tezy, którą mamy w głowie, to pewnie ją udowodnimy.
Temat bazowy to nie może być temat potrzebny do spełnienia potrzeb regulatora, ponieważ wiadomo, że ten temat i tak zostanie zrobiony. Tematem bazowym nie może być temat absolutnie kluczowy, ponieważ logiczne jest, że inne wypadną przy nim słabo.
Do tabelki można dołożyć wiersz z relatywnym kosztem Tematu. Do tego będzie potrzebne relatywne oszacowanie wielkości i potrzebnych capabilities technicznych.
Kiedy i jak wykorzystywać Theme Screening?
Naturalnym momentem stosowania Theme Screening jest początek pracy nad produktem, kiedy być może nie mamy jeszcze zespołu, określamy zgrubny zakres i budżet. Drugi dobry moment to zaplanowanie wydań czy zbudowanie roadmapy, kiedy decydujemy o dostarczaniu wartości do klienta.
Theme Screening naturalnie nadaje się do przeprowadzenia w formie warsztatów. Oczywiście dobrym pomysłem jest, żeby na warsztatach pojawili się interesariusze. Product Owner prowadzi taki warsztat, a Scrum Master pomaga facylitować.
Można używać arkusza kalkulacyjnego na rzutniku, tablicy suchościeralnej. Można też skorzystać z narzędzia online od Mike’a Cohna, chociaż byłbym ostrożny z wysyłaniem priorytetów i celów biznesowych mojej organizacji do strony internetowej należącej do innej organizacji.
Poznałeś nowe narzędzie? Dobrze byłoby wykorzystać je w praktyce jak najszybciej. Niedługo post o Theme Scoring — dołożymy trochę złożoności do Theme Screening.
