Pamiętacie o Value Points? A może w ogóle nigdy o nich nie słyszeliście? Spokojnie, nikogo to nie zdziwi. Przecież i tak mało kto w ogóle pamięta, żeby szacować i zapisywać wartość poszczególnych wymagań.
Value Points oznaczają wartość
Gdybyśmy zrobili szeroki scrumowy audyt, to na pewno okazałoby się, że w typowym backlogu nie znajdziemy nawet śladu po jawnie zdefiniowanej wartości. Wróćmy więc do samego początku, czyli do naszego starego dobrego Scrum Guide’a.
„Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.” – Scrum Guide
Z trzema z tych obowiązkowych atrybutów nie mamy żadnych problemów. Bo zawsze przecież musi być jakiś opis wymagania. Kolejność również jest oczywista. Często też wymuszają ją używane narzędzia, jak np. popularna Jira. Nie da się tam przecież ustawić dwóch elementów obok siebie. Z kolei oszacowanie wymusza albo Development Team, albo zależy na nim Product Ownerowi.
No i zostajemy z wartością, o której zwykle absolutnie nikt nie pamięta. Czasami zdarzy się Product Owner, który będzie ją określał na swoje prywatne potrzeby, ale zwykle dzieje się to na poziomie Epika, wyrażone jest w złotówkach i liczba ta nigdy nie trafia do backlogu. A nie o to nam chodzi.
„Właściciel Produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.” – Scrum Guide
Z jakiegoś powodu wyraźnie zostało zapisane, że wartość musi znajdować się przy wszystkich Elementach Backlogu Produktu. W Scrumie nie ma elementów zbędnych. Ten zapis ma za zadanie zmusić PO do myślenia o celu zwinności, czyli o wartości dostarczanej dla użytkownika końcowego.
Jak wyznaczyć wartość?
Value Points to nic innego jak odpowiednik Story Points, ale w ujęciu wartości dostarczanej dla naszego odbiorcy. To znaczy, że porównując wymagania między sobą określamy „na czym naszemu klientowi bardziej zależy” bądź „z czego będzie bardziej zadowolony”.
Podobnie jak wspomniane oszacowanie, tak i Value Points są miarą względną. To znaczy, że nie staramy się określić „ile skorzystamy na tym wymaganiu”, tylko „jak się ma wartość poszczególnych wymagań w stosunku do siebie”. Chcemy je porównywać między sobą, więc będziemy unikać słynnego już ROI czy szacowania w złotówkach.
Jeżeli już wprowadzamy miarę punktową wartości, to zwykle korzystamy z dobrze znanego zbioru opartego o ciąg Fibonacciego. To nasze dobrze znane 1, 2, 3, 5, 8, 13, 21, 34, 55, itd. Pamiętamy przy tym, że te wartości mają znaczenie jedynie w przypadku porównywania między sobą wymagań dotyczących jednego produktu. Na pewno nie próbujemy przeliczać ich na żadną twardą walutę.
Oczywiście Value Points to nie jest jedyny sposób na zapisanie wartości w naszym backlogu. Równie dobrze możemy skorzystać z innych miar względnych, jak na przykład rozmiaru koszulek (S, M, L, XL) bądź opisywanej już przez nas metody MoSCoW. Ona też w pewien sposób opisuje wartość i również nadaje się do porównywania wymagań między sobą.
Niezależnie od wybranej miary chcemy dzięki temu pomóc zrealizować cel PO, jakim jest dostarczanie jak najprostszych wymagań o jak najwyższej wartości. W tekście pod tytułem „3 grzechy Product Ownera” Łukasz słusznie zauważył, że bardzo często PO jest z wartością na bakier. I nie chodzi tu nawet o to, że nie używa on Value Points tylko o sam fakt, że taka cecha jak wartość jest totalnie ignorowana.
Wydaje się jednak, że skoro już szacujemy wielkość wymagań, to w podobny sposób łatwo będzie określić ich (względną) wartość. Dzięki temu jasno jak na dłoni zauważymy wymagania, które np. są wycenione na 2 punkty, ale mają wartość równą 13 i takie, gdzie sytuacja będzie dokładnie odwrotna. I nawet jeśli i tak z jakiegoś powodu wylądują one na szczycie backlogu, to przynajmniej zmusi to wszystkich zainteresowanych do dyskusji na ten temat.
A to buduje zarówno zrozumienie, jak i zapewnia transparentność.
Problemy z Value Points
Są dwa główne wyzwania, które materializują się gdy zaczynamy rozmawiać o wartości. Pierwsze dotyczy sposobu precyzyjnego określania Value Points, a drugie – zapisania tego w backlogu i późniejszego korzystania z tej miary do priorytetyzacji.
Pamiętajmy, że backlog to nie jest apteka. Value Points mają jedynie służyć pomocą Produt Ownerowi w wyborze kierunku, w jakim chcemy rozwijać nasz produkt. Są one też przydatne na Sprint Review do rozmów z interesariuszami. Ale musimy mieć świadomość, że jest to tylko i wyłącznie zgrubne oszacowanie.
\Zupełnie zaś nie mam pojęcia, skąd się bierze niechęć do fizycznego zapisywania wartości przy elementach znajdujących się w backlogu. Wydawałoby się oczywiste, że chcemy mieć pełną transparentność i widzieć, co robimy i po co. Taka informacja będzie wtedy przydatna dla każdego. Może niektórzy PO mają świadomość, że robią mało wartościowe rzeczy i starają się ukryć to przed zespołami?
A może jest tak, że Product Ownerom wydaje się, że dobrze wiedzą, które wymagania są tymi najbardziej istotnymi? Może w ogóle nie czują potrzeby wyznaczania i zapisywania Value Points?
Takie myślenie jest bardzo złudne. Jak wiemy dzięki tekstom i filmom o błędach poznawczych, nie możemy sobie do końca ufać. Jeżeli coś nie jest jawnie zapisane, określone i policzone, bardzo często będziemy podejmować decyzje w oparciu o nasze serce, a nie rozum. Dlatego też zachęcamy wszystkich do zmierzenia się z tym wyzwaniem i określeniu wartości dla wszystkich elementów Backlogu Produktu.
I nie trzeba w tym celu korzystać z Value Points. Wystarczy nawet zgrubne jej oszacowanie rozmiarami koszulek. Ale spróbujcie przeprowadzić to ćwiczenie i przekonać się na własnej skórze, co się zmieni. Bo naszym zdaniem – zmieni się dużo i to na korzyść.
