Jak mamy dostarczać produkty o najwyższej możliwej wartości, jeżeli jej w ogóle nie mierzymy? Ba! Bardzo często Rejestr Produktu (zwany także Product Backlogiem) nie definiuje jej w ogóle. Co nam grozi?
Wartość, a Rejestr Produktu
Rejestr Produktu to polska (niektórzy mówią, że polskawa) nazwa na najlepszego przyjaciela każdego Product Ownera, czyli backlog. Popełniliśmy już o nim wiele tekstów i filmów. Na szczególną uwagę zasługuje między innymi popularny post omawiający Product Backlog Refinement.
„Product Backlog items have the attributes of a description, order, estimate, and value.” – Scrum Guide
PBI, czyli Product Backlog Item to każdy element w Rejestrze Produktu. Mówiąc wprost – może to być wymaganie, potrzeba biznesowa bądź zadanie do realizacji (np. poprawa błędu). Zgodnie z definicją, każdy taki ERP („Element Rejestru Produktu”) powinien posiadać co najmniej opis, kolejność, oszacowanie i wartość.
Niestety, bardzo często będzie posiadał trzy z czterech wymienionych powyżej atrybutów. W gratisie za to dostaniemy nazwę i unikalny identyfikator. Czego zabraknie? Bohatera naszego dzisiejszego tekstu.
Rzeczą, której brakuje w większości backlogów jest wartość. I nie chodzi tutaj wcale o szacowanie ROI, czyli „ile na tym zarobimy w twardej walucie”. Chociaż oczywiście, jak najbardziej możemy iść w tym kierunku, pod warunkiem, że potrafimy to policzyć. Na pewno dyskusja nad tym będzie bardzo na miejscu dla naszych ogólnych potrzeb biznesowych, czyli Epików. A co z User Story?
Zawsze możemy skorzystać z Value Points, chociaż nie do końca polecam tę drogę, bo mieszają się one w głowach ze Story Points. Dobrym kandydatem na wartość jest za to metoda MoSCoW, a także rozmiary koszulek i prosta lista wartości „niska, średnia, wysoka”.
Teoria głosi, że każdy element w Rejestrze Produktu powinien mieć zdefiniowaną wartość. Ale czy dla każdego z nich jesteśmy w stanie ją przypisać? I po co?
Bezwartościowe, ale niezbędne
A co z wymaganiami, które nie są dla nas wartościowe, ale są niezbędne do realizacji? Typowym przykładem są tutaj wszystkiego typu regulacje prawne i konieczność dostosowania się do zmieniających się warunków technicznych. Bo ktoś może zapytać „To jaka jest wartość tego, że dostosujemy nasz system do zmieniającego się API dostawcy? Przecież z punktu widzenia klienta nic się nie zmieni!”
Wracamy tutaj do naszego ulubionego zagadnienia prosto z wystąpienia pod tytułem „Najważniejsze zwinne pytanie, którego nikt nie zadaje„. Mówiąc wprost i nieco brutalnie – skoro w naszym Rejestrze Produktu znajdują się rzeczy bezwartościowe, to ich po prostu nie róbmy. „Nie możemy, grożą nam za to wymierne konsekwencje!” A skoro tak, to właśnie odkryliśmy ich wartość.
Wartość to nie musi być potencjalny zysk, ale może to też być uniknięcie potencjalnej kary. Patrząc w ten sposób, prawie zawsze jesteśmy w stanie określić korzyści, które płyną z naszych rozwiązań.
Jasne, jeżeli robimy refactoring kodu, walczymy z długiem technologicznym bądź budujemy nowe funkcjonalności z nadzieją, że kiedyś znajdziemy dla nich rynek zbytu, to trudno może być nam określić sensowną wartość. To może w ogóle sobie ją darować?
Pamiętajmy, że zgodnie z ideą transparentności, informacja o braku informacji jest bardziej pożądana niż przemilczenie tego faktu. Jeśli przy części naszych wymagań i potrzeb biznesowych będziemy umieszczać adnotację „wartość trudna do określenia” czy „prawdopodobnie zerowa”, to jest to lepsze niż pominięcie jej w całym Rejestrze Produktu.
Wartość w skali mikro
Powyższe rozważania dotyczą bardziej Epików i ich priorytetyzacji przez Product Ownera. Ten oczywiście nie robi tego sam. Bardzo często wartość nadawana jest w porozumieniu z interesariuszami. Ba, często to oni są w stanie wyznaczyć ją dokładnie(j) i będą jej używali chociażby do wspólnego Release Planningu.
Co jednak na poziomie Sprintów i poszczególnych, często bardzo drobnych, wymagań? Po co mamy sobie zaprzątać głowę wpisywaniem cokolwiek w to pole?
Cóż, z wartością w Rejestrze Produktu jest tak samo, jak z uzasadnieniem „aby…” w User Story. Niektórym przyda się to jako istotna informacja pozwalająca podejmować trafne decyzje. Dla reszty sama próba określenia wartości będzie przydatnym ćwiczeniem, które zmusi nas do zadania niewygodnych pytań.
Zresztą, Rejestr Produktu zawierający wartość jest prostszy do uporządkowania. Product Owner od razu widzi elementy, które są duże i mało wartościowe oraz te, które niewielkim nakładem pracy mogą dać dużą wartość. I nawet jeśli koniec końców musimy zrobić wszystko, to skupiając się na tym, co wartościowe, szybciej dostarczymy MVP oraz damy sobie szansę na lepsze dopasowanie produktu do odbiorcy.
Czy jest to absolutnie niezbędny element Scruma? Według podręcznika – tak. Ja za to powiem to, co zawsze mówię przy tego typu pytaniach – spróbujcie, bo zanim nie spróbujecie, nie będziecie wiedzieli czy przypadkiem Wam to nie pomoże. To jest przecież ten słynny empiryzm.
I nawet jeśli nie wierzycie w wartość na poziomie User Stories i poszczególnych Sprintów, to spróbujcie zacząć od Epików. Dajcie sobie szansę.
