O co se jedná?

• Vizualizace uživatelského toku v čase – vizualizuje akce, které dělá uživatel v systému, aby dosáhl (předem) definovaného cíle.
• Užitečný nástroj na tvorbu kostry Backlogu pro Tým nebo Squad.
• Výsledná mapa pomáhá týmu a Product Ownerovi s prioritizací a určením toho, co je pro zákazníka skutečně důležité.
• Prvním výstupem User Story Mappingu je množina User Stories, které dohromady tvoří MVP (Minimal Viable Product).

Jak metodu použít?

1. Vyberte zástupce různých rolí – Vývojář, Designér, Tester, Product Owner (ideálně max. 10 lidí).
2. Požádejte Product Ownera o sepsání krátkého popisu toho, co je potřeba zmapovat, ideálně ve formátu:
   1. CO? – produkt, nová funkcionalita, kterou chce přidat, nebo problém, který potřebuje vyřešit;
   2. PRO KOHO? – popisuje zákazníky produktu nebo uživatele, kteří budou danou funkcionalitu využívat. Pro každého takového uživatele explicitně popsat, co mu to přináší;
   3. PROČ? – popisuje důvod, proč se firma rozhodla danou funkcionalitu nebo produkt vytvořit.
3. Vyhraďte si 2-3 hodiny času a prostor s velkou tabulí nebo zdí.
4. Začnete představením vstupu Product Ownera a pokračujte společnou definicí:
   1. Startovacího bodu – bod, ve kterém uživatel vstoupí do systému, začne svou interakci (např. Uživatel se přihlásí do webového rozhraní internetového bankingu);
   2. Cílového stavu – cílový stav, kdy je potřeba firmy/zákazníka naplněna (např. Uživatel provedl finanční transakci).
      

1. Společně ve skupině vytvořte tzv. Páteř (Backbone) Story Mapy tak, že pojmenujete větší aktivity, které uživatel musí v systému udělat, aby dosáhl cíle definovaného v minulém kroku. Aktivity vizualizujte na zdi/tabuli zleva doprava tak, jak jdou za sebou v čase.

1. Každou aktivitu rozpadněte na menší části – tzv. Uživatelské úkoly (User Tasks). Přemýšlejte nad:
   1. Alternativními způsoby, jak lze danou aktivitu v systému realizovat;
   2. Jaké okrajové případy mohou nastat (něco nebude fungovat, spadne server apod.)?
   3. Jak by k dané aktivitě přistupovali různí uživatelé systému?
   4. Detaily aktivity a různými vylepšeními;
2. Při tvoření se snažte vertikálně prioritizovat podle hodnoty a důležitosti daného zákaznického úkolu.

1. Vyznačte na mapě první nejmenší řez zleva doprava, kterým je zákazník schopen dosáhnout definovaného cíle – vzniká MVP release (na obrázku znázorněn červenou čarou).

1. Pokračujte vyznačením dalších řezů, z nichž každý přidá další novou ucelenou funkcionalitu pro zákazníka. Platí pravidlo – 1 řez = 1 release. Při určování dalších řezů můžete zvažovat:
   1. Různé persony – můžete zacílit konkrétní inkrementy/release na konkrétní typy uživatelů (např. po doručení MVP se zaměřit na firemní zákazníky a na základě toho prioritizovat jednotlivé uživatelské úkoly);
   2. Přidání dalších klíčových možností a alternativ do produktu podle důležitosti nebo nejčastějšího způsobu využití.

1. Po vybudování User Story Mapy a vydefinování řezů můžete výsledek “překlopit” například do JIRA a máte tak vytvořený iniciální Backlog.
   1. Jeden řez reprezentuje ideálně jeden Epic.
   2. Priorita v Backlogu je dána řezem shora dolů a pak po sloupcích zleva doprava (viz. čísla v pravém dolním rohu kartiček na obrázku).

Kdy není technika vhodná?

• Nový produkt nebo funkcionalita nevyžaduje žádné nebo pouze minimálni interakce uživatele v systému (např. technické změny na pozadí, refaktoring apod.).
• Nová funkcionalita je pouze malá změna v obrovském fungujícím systému (mapování stávajícího systému by zabralo hodně času).
• Chcete si pouze namapovat Stories, které už máte předem vymyšlené (lidé nebudou brát výsledek za svůj, protože je už vše dáno dopředu).
• Pokud nejste schopni svolat na jedno místo dostatek rozdílných rolí – můžete přijít o důležité nápady, perspektivy, otázky, poznatky (minimum je Product Owner, Vývojář, Tester a Designér).

Pokud byste si chtěli vyzkoušet techniku v praxi, neváhejte se nám ozvat, velmi rádi vás workshopem provedeme od začátku až do konce na konkrétním příkladu z vaší praxe.

‍