„Jako uživatel chci…“ – a tady to někdy končí. Zbytek si domyslete🙈. User stories jsou základní stavební jednotkou backlogu, přesto někdy mohou připomínat spíš hádanku než smysluplný požadavek. Pojďme si ukázat, jak poznat opravdu dobrou user story, proč se vyplatí ji psát pečlivě – a jak tím ušetříte čas, nervy a nejedno rozčarování na sprint review sobě i celému týmu.
Začneme lehkým opáčkem: User story – pojem skloňovaný v agilním vývoji a business analýze – je v jádru krátký „příběh“ popisující požadavek z pohledu uživatele. Na rozdíl od sáhodlouhých specifikací se user story soustředí na tři jednoduché věci:
- kdo něco potřebuje
- co je to to, co potřebuje a
- proč to potřebuje.
Formálně zapsáno:
„Jako [uživatel] chci [funkcionalitu], abych [něco získal]“
Přestože tato formulka vypadá jednoduše, napsat user story kvalitně rozhodně jednoduché není.
Pojďme rovnou na to: dobrá user story má několik poznávacích znaků..
Má kontext. Tedy vždy jasně říká, kdo z ní bude mít užitek. Začíná typicky „Jako [uživatel]…“, což dává týmu kontext, pro koho je funkce určena. Namísto obecného požadavku „Potřebuji export dat“ nám use story: „Jako finanční manažer chci exportovat data, abych mohl připravit měsíční uzávěrku“ řekne mnohem víc o tom, co se po nás vlastně chce.
Obsahuje přínos (hodnotu). Důležitá část „…abych [něčeho dosáhl]“ zaručuje, že story má smysl a cíl. Popisuje konkrétní přínos pro uživatele nebo byznys, ať už je to úspora času, lepší zážitek nebo vyřešení nějakého problému. Když budeme vědět, co má daná funkcionalita přinést, umožní nám to lépe prioritizovat.
Je konkrétní. Kvalitní user story není vágní přání typu „Zlepšit výkon systému“ nebo „Udělat aplikaci modernější“. Ideálně popisuje jednu funkci nebo scénář. Pokud je story příliš obecná nebo obsáhlá, je fajn ji rozdělit na menší části. (Existuje dokonce pomůcka INVEST, která říká, že dobrá user story má být i nezávislá a malá – aby šla dokončit v jednom sprintu.)
Má akceptační kritéria. S user story by měla jít ruku v ruce jasná akceptační kritéria, která definují podmínky úspěchu. Jsou to konkrétní podmínky, za kterých je story hotová a splněná. Jak definuje agilní kouč Mike Cohn, akceptační kritéria jsou vlastně „poznámky o tom, co musí user story splňovat, aby ji produktový vlastník mohl považovat za dokončenou“. Kritéria přidávají detail, dávají týmu společné porozumění a jsou podkladem pro testování. Například u story „Jako zákazník chci zaplatit kartou“ mohou akceptační kritéria zahrnovat scénáře platby platnou kartou, expirovanou kartou, nedostatečný zůstatek apod. – zkrátka jasně vymezují, co vše se musí ošetřit, aby byla funkce považována za dokončenou.
Je srozumitelná. User story by měla být napsána jazykem, kterému rozumí byznys i vývojáři. Vyhýbáme se odbornému žargonu, pokud to není nutné, a dáváme pozor na dvousmyslné nebo nejasné formulace. Každý člen týmu by si měl pod textem představit totéž – pokud ne, je to varování, že je potřeba doplnit detail či upravit formulaci. Stručnost je ctnost, ale nesmí to být na úkor jasnosti.
Podněcuje diskusi. Paradoxně, i ta nejlépe napsaná user story není kompletní specifikace. A ani nemá být – jejím účelem je vyvolat konverzaci v týmu. Agilní expert Roman Pichler trefně poznamenává, že „user story není specifikace, ale nástroj ke spolupráci“. Karta user story (třeba v Jira) je jen výchozí bod; to nejdůležitější se odehrává v rozhovorech nad ní – když si vývojáři, testeři a produktový manažer společně vyjasňují detaily. Diskuse nad user story často odhalí přehlédnuté scénáře a upřesní očekávání. Právě díky tomu předejdete tomu, že by každý člen týmu měl o funkci jinou představu. Mike Cohn dokonce říká, že každá user story je hlavně „placeholder neboli připomínka budoucí konverzace“. Když je v textu story něco nejasného, tým se musí doptat – a to je žádoucí jev. Kvalitní user story tedy nešetří slovy proto, abyste se méně bavili; naopak, má povzbudit všechny zúčastněné k dialogu.
Chcete se o ovládnutí User Stories dozvědět víc? Svou poznávací cestu můžete začít třeba na tomhle kurzu od Beanz s.r.o.
