Techniki Priorytetyzacji #1 ‑Theme Screening

Rozpoczynamy cykl artykułów o technikach priorytetyzacji. Można powiedzieć, że są to artykuły o zapomnianych technikach priorytetyzacji. Te techniki mają już swoje lata, ale jakoś się tak wydarzyło, że bardzo rzadko a nawet wcale nie widuje się ich w praktyce. Cześć z tych technik pojawiła się już w książkach w późnych latach 90-tych ubiegłego wieku. Większość określania priorytetów dzisiaj jest przeprowadzana techniką mokrego palca.

Dlaczego Piorytetyzacja?

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 Backlog 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 na Product Backlog, to temat na posta 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 rozchodzi 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 jest jak to Amerykanie mówią porównywanie jabłek i pomarańczy. A jednak w żyiu 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ękuje Ł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 Piorytetyzacja Tematów?

Temat to wysoko poziomowy 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 Backlog 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 Selekcja 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 tak samo wpływa na osiągnięcie celu, jak Temat bazowy to w komórce wpisujemy 0. Na końcu sumujemy Kolumny sumujemy 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:

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 nie może to być temat potrzebny do spełnienia potrzeb regulatora, ponieważ wiadomo, że ten temat i tak zostanie zrobiony. Tematem bazowym nie może to być temat absolutnie kluczowy, ponieważ logicznym 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 Cohn’a, 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.