User Story Mapping framework

Tomáš Veselý - podpořen AI
2. 1.
Minut čtení: 7

Tvoříme obsáhlou knihovnu znalostí o produktovém vývoji jako součást naší mise. Knihovna slouží všem, kteří se snaží zlepšit v rozhodování, především v rozhodování o dalším rozvoji produktu. Ať už jsi vynálezce, produktový manažer nebo Chief Product Officer, používání určité rozhodovací metody zvyšuje šanci na vytvoření správných produktů a jejich funkcí pro správné publikum (build the right thing for the right audience). Dnes si představíme Value User Story Mapping framework.

Název frameworku: User Story Mapping.

Vynálezce: Mike Cohn, Rachel Davies, Jeff Patton je vynálezce mapovací techniky, ostatní hlavně přispěli formátem story.

Rok prvního použití: 2008 a pár let předtím.

Odkaz na původní výzkum: článek The New User Story Backlog is a článek Map a How You Slice It.

Důležité osobnosti v rozvoji frameworku:

Mike Cohn,
Rachel Davies.

Důležité milníky v rozvoji frameworku:

Článek It’s All in How You Slice z roku 2005,
Rozvoj formátu hlavně ve spojení s extreme programming metodou,
Zapojení do agilního vývoje,
Přidání systematičnosti skrze mapování.

Historie a kontext použití

Jeff Patton, zakladatel mapovací techniky zvané User Story Mapping, si během své kariéry konzultanta všiml, že při vývoji softwaru agilním způsobem týmy ztrácejí pochopení toho, jakou hodnotu má zamýšlený produkt přinést zákazníkovi. V průběhu tvorby nového produktu se týmy až moc soustředily na jednotlivé User Stories a jejich dokončení, a ne na celkovou hodnotu pro zákazníka.

Běžně se stávalo, že jednotlivé User Stories byly seřazeny do backlogu, jakéhosi velmi dlouhého listu funkcí seřazeného podle priorit. List se časem stal symbolem mizernosti vývoje. Vývojář, vysoký manažer, konzultant i produktový manažer na něj mohl zírat hodiny a stále odcházel s pocitem, že tam něco chybí.

Prioritizace tohoto listu se stala úmorným procesem, ve kterém se celý produkt smrskl na pár vět, jež se donekonečna otáčely, zlepšovaly, měnily, až nikdo nevěděl, jakou hlavní hodnotu daný produkt má. List nedokázal být efektivním komunikačním médiem, ale byl všemi preferován jako správná agilní metoda.

Základní princip prioritizace

Základním kamenem frameworku je vizualizace hlavní hodnoty produktu z pohledu uživatele a vedlejších hodnot, které jsou s ní spojené. Mapa přináší hloubku důležitosti vedlejších funkcí vzhledem k páteřním funkcím produktu.

Tento holistický pohled na produkt slouží jako pomůcka pro určení priorit funkcí, které nejsou součástí páteře produktu.

Proces tvorby mapy má celkem pět kroků. Cílem je vytvořit celkový pohled na hodnotu určitého produktu a její následné vizuální porovnávání, které vede k tvorbě jednotlivých setů funkcí na vývoj. Vizualizace pomáhá odhalit minimální počet nepáteřních funkcí, které dokáží doručit jakýkoliv cíl produktu.

User Story

Základem celého procesu je tzv. User Story. Jedná se o formát komunikace hodnoty pro uživatele. Formát má následující textaci:

Anglický originál = As a (who wants to accomplish something) I want (what I want to accomplish), so that I (why I want to accomplish it).
Česky přeloženo = Já jako (někdo, kdo chce něco dokázat) chci (co chci dokázat), abych (proč to chci dokázat).

Následující příklad pomůže formát lépe pochopit: Já jako B2B produktový manažer chci analyzovat kohorty zákazníků podle retence, abych mohl lépe pochopit, jaké funkce mají dopad na retenci a jaké ne.

Veškeré funkce, okoly, aktivity v rámci tvorby mapy jsou psané v tomto formátu.

Mapování User Stories

Celé mapování jednotlivých User Stories do vizuální mapy je prováděno ve skupině lidí důležitých pro zamýšlený produkt. Nejen tedy vývojářů, ale i lidí z byznysu. Cílem mapování je vytvořit vizuální příběh, jak celý produkt funguje.

Krok 1.

Na začátek je potřeba, aby někdo sepsal nebo řekl:

kdo jsou zákazníci daného produktu,
co je hlavní hodnotou produktu a,
jaké hlavní cíle má organizace směrem k tomuto produktu.

Tyto informace jsou základem celého frameworku a většinou přicházejí od seniorních členů týmu. Pro efektivní komunikaci těchto informací se dá využít například Value Proposition Statement framework.

Vizuální ukázka User Story Mapping krok 1

Krok 2.

Zákazníci mají vždy nějaký cíl, kterého se snaží dosáhnout pomocí daného produktu. My se tento cíl snažíme zvizualizovat formou organizovaných user stories. Vytváříme páteř celého produktu, jeho hlavní hodnotu pro uživatele, která nám také slouží jako kontext hodnoty produktu.

Postupně mapujeme kritické aktivity, které uživatel vykonává na cestě k dosažení svého cíle. Představa, jak vypadá typický den zákazníka se zamýšleným produktem, je většinou dobrým startovním bodem pro tento krok.

Tyto aktivity zapíšeme formou User Story. Tím nám vznikne vizuální příběh, chronologický postup, jak uživatel dosahuje svého cíle pomocí zamýšleného produktu, a to ve formě časové osy, kterou čteme zleva doprava.

Pokud má uživatel více cílů, můžeme je zapsat nad páteřní aktivity. Většinou ale uživatel, a tedy i produkt, má jeden hlavní cíl s mnoha subcíli. Aktivity, které nejsou páteřní, ale jsou s nimi spojené, začneme formou User Stories vkládat do sloupce pod páteřními aktivitami.

Vizuální ukázka User Story Mapping krok 2

Krok 3.

Je čas kreativní exploze. Vedlejší aktivity, které jsme v druhém kroku doplnily pod páteřní aktivity, nyní obohatíme o další aktivity. Rozdělujeme vedlejší aktivity na menší a ještě menší, ptáme se „co když?“ a přidáváme další a další User Stories, které dělíme na menší aktivity.

Naším kompasem při výběru nových a často méně důležitých úkolů by mělo být jejich logické spojení s nadřazenou páteřní aktivitou a cílem.

Výsledkem třetího kroku je finální mapa všech aktivit kategorizovaných do skupin podle cílů a páteřních úkolů, která je navíc chronologicky seřazená v čase. Je to příběh hodnoty produktu pro zákazníka.

Vizuální ukázka User Story Mapping krok 3

Krok 4.

Čtvrtý krok je věnovaný prioritizaci. Neprioritizují se páteřní aktivity, protože bez nich produkt nebude fungovat jako celek, tedy jejich vytvoření je nutným předpokladem uvedení produktu na trh.

Vedlejší aktivity v jednotlivých sloupcích seřadíme tak, aby horizontálně tvořily vždy jednu verzi produktu a vertikálně prioritu vývoje. Tlustou horizontální čárou mezi vedlejšími aktivitami oddělíme jednotlivé verze produktu.

Každá verze produktu je set minimálního množství funkcí, které jako celek doručí určitý cíl. Cíl může být stanoven byznysem, ale měl by být vždy v kontextu celého řešení, tedy páteřních aktivit a uživatelových cílů.

Klíčovým bodem je stanovení úspěchu každé verze produktu prostřednictvím souboru kritérií, která ukáží, zda daná verze cíle skutečně naplnila.

Vizuální ukázka User Story Mapping krok 4

Krok 5.

Pátý krok je doplňkový, určený pro strategii exekuce vybrané verze produktu. Tuto verzi lze nyní rozdělit na tři a více releasů. Tímto dělením snižujeme riziko nedoručení hodnoty zákazníkovi, ale i riziko nesplnění dodání v komunikovaném termínu. Po každém release se můžeme zastavit a vyhodnotit situaci.

Ideálním pravidlem, jak podle frameworku dělit verze produktu, je podle šachové strategie. Každý produktový release můžeme rozdělit na:

Začátek hry (Opening Game) = cílem je vystavět tzv. functional walking skeleton, tedy nejjednodušší možný set funkcí, který splní hodnotu pro zákazníka a umožní validaci jeho hodnoty.
Střed hry (Mid Game) = cílem Mid Game je přidat všechny důležité funkce, které rozšíří produkt a vytvoří pocit kompletnosti.
Zakončení hry (End Game) = funkcionality v zakončení poté cílí na vyladění bugů, výkonnosti produktu a scénáře, které nebyly zachyceny během minulých releasů.

Krok pět lze opakovat ke každé nové verzi produktu.

Vizuální ukázka User Story Mapping krok 5

Mapování pro již existující produkt

Ne vždy produktový manažeři začínají se zcela novým produktem. Velmi často přidávají nové funkce do stávajícího produktu. Tento produkt již má páteřní funkce, které uživatelé používají. V tomto momentě je na zvážení, zda vytvářet celou User Story Mapu, nebo si jen načrtnout páteřní funkce a zprioritizovat si oproti nim nové User Stories. Druhá možnost je časově méně náročná.