Produkty sú agilnými tímami vytvárané tak, aby dodávali používateľom čo najskôr hodnotné funkčnosti. Neraz je táto hodnota označovaná aj ako biznis hodnota alebo pridaná hodnota.
Prioritizácia požiadaviek (eposov a user stories) má byť teda primárne založená na tejto biznis hodnote. No mnoho produktových vlastníkov sa pýta: „Čia je to biznis hodnota?“ Je to biznis hodnota klienta? Alebo moja? Alebo je to hodnota podľa obchodného modelu našej firmy?
Všetky tieto otázky sú relevantné. Asi najlepšou opoveďou je, že v skutočnosti je biznis hodnota funkciou:
BV = f ( klient, biznis model, partneri, ….)
Niekedy je vlastnosť predaná klientovi, ktorý je ochotný za ňu aj zaplatiť. Inokedy musím ja, produktový vlastník, vytvoriť vlastnosť, ktorá prinesie produktu nový trh, nových klientov alebo partnerov. V tomto prípade neexistuje klient, ktorý by za vlastnosť platil. Môže sa vám stať aj to, že vlastnosť prinesie hodnotu vašim partnerom, ktorí následne umožnia získať hodnotu aj pre váš produkt.
Prioritizácia? Poradie?
Základnou úlohou produktového vlastníka je mať poriadok v produktovom backlogu.
Mať jednoznačné priority. Mať jednoznačné poradie.
Biznis hodnota sa prirodzene ponúka ako argument pre rozhodovanie. Je však chybou si myslieť, že je to jediný argument pre stanovenie poradia.
Často sa totiž zabúda na to, že nie všetky požiadavky sú ‚MUST‘. Nie všetky sú ‚SHOULD‘. Možno sú aj niektoré COULD. Premyslením si nutnosti môže produktovému vlastníkovi zvalidovať biznisovú hodnotu, ktorú odhadoval.
Ďalším argumentom by malo byť riziko. A odhad rizika robia iba máloktoré agilné tímy. Často preto, že je to ‚postup tradičného manažmentu‘ alebo preto, že nie je ochota sa nad ním zamýšľať.
Je chybou na riziko zabúdať. Potom sa vám priority user stories v backlogu pomiešajú tak, že vytvárate nepotrebné, odpad.
Riziko verzus hodnota
Jednoduchý diagram Riziko verzus hodnota pomôže rýchlo identifikovať práve takéto zbytočnosti.
Každá bodka reprezentuje user story. Jej farba reprezentuje stav.
Na X osi je biznis hodnota. Na Y osi je hodnota rizika. Vznikne tak matica, ktorá rozdelí backlog na štyri časti:
– Spraviť ako prvé.
– Spraviť ako druhé.
– Spraviť ako posledné.
– Zabudnúť.
Čo vidíme na tejto vizualizácii reálneho backlogu komerčného produktu?
Obrovský problém. Tím vytvoril vlastnosti, ktoré boli zbytočné. A bolo ich mnoho. Rozloženie je síce dané aj tým, že existuje iba jedna user story s biznis hodnotu 200, čo posunulo stred grafu doprava a tak sa viacero user stories dostali do segmentu Avoid. No aj keby bol stred na hodnote BV=50, aj tak nájdeme päť user stories, ktoré nemali byť vôbec vyvinuté. Päť user stories sa implementuje v 1-2 sprintoch. Tím si tak mohol ušetriť prácu 2-4 týždne!
Pre produktového vlastníka je tento stav indikácia zváženia priorít. Vývojový tím by mal tiež upozorniť produktového vlastníka, či skutočne sú priority obchodne správne.
Rizikové vlastnosti, ktoré majú nízku hodnotu, tak nebudú vytvárané. Pretože to je veľký nezmysel.
