User Story Mapping

Zažili jste někdy situaci, kdy máte před sebou obrovskou věc a nevíte z které strany začít? Řešíte, jak uchopit rozpad nové funkcionality tak, abyste co nejdříve dodali zákazníkovi co největší hodnotu a až poté dělali na dalších částech? Právě pro vás může být velmi užitečná metoda User Story Mapping, která se používá pro rozpad velkých celků na menší. Připravili jsme pro vás proto praktický návod krok za krokem, který vás technikou provede.

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).

5. 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.

6. 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;
7. Při tvoření se snažte vertikálně prioritizovat podle hodnoty a důležitosti daného zákaznického úkolu.

8. 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).

9. 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í.

10. 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.

Zaujal vás text? Jeho původní verzi najdete na blogu RainFellows.