User Stories

User story je krátký popis funkcionality z pohledu uživatele. Když je napsaná dobře, vývojáři pochopí co a proč mají udělat. Když špatně, vzniknou nedorozumění a přepracovávání.

User story není specifikace. Je to vzor pro konverzaci mezi product managerem, vývojáři a dalšími členy týmu.

Základní formát: Jako [typ uživatele] chci [akce/funkce] , abych [důvod/hodnota].

Příklad: Jako majitel e-shopu chci exportovat objednávky do CSV, abych je mohl importovat do účetního systému.

Tento formát nutí autora zamyslet se nad třemi věcmi:

1. Kdo to potřebuje (ne všichni uživatelé jsou stejní)
2. Co konkrétně chce udělat
3. Proč to potřebuje (jaký problém řeší)

Nejdůležitější je důvod

Část „abych…“ se často vynechává nebo je napsaná obecně. To je chyba, protože tak vynecháváme důležité informace a souvislosti, které pak můžou mít zásadní význam pro způsob provedení.

Porovnejte třeba „Jako uživatel chci dark mode.“ versus „Jako uživatel, který pracuje večer, chci tmavý režim rozhraní, abych měl menší únavu očí při dlouhé práci.“

Proč je to lepší? Protože vývojář chápe kontext: nejde jen o „cool feature“. Cílem je snížit únavu očí a možná existují i jiná řešení (automatické ztlumení, noční režim podle času). Když neznáte „proč“, nemáte user story, máte jen přání.

INVEST kritéria

Dobrá user story by měla splňovat následující kritéria INVEST:

Independent: story by měla být realizovatelná samostatně. Pokud story A závisí na story B, máte problém s plánováním. Rozdělte jinak, nebo spojte do jedné story.

Valuable: každá story by měla přinést hodnotu. „Refaktoring databázové vrstvy“ není user story – uživatel z toho nemá nic. Technické úkoly formulujte jako něco, co umožňuje další úkoly, nebo je skryjte do stories s viditelnou hodnotou.

Small: story by měla být dostatečně malá, aby ji tým zvládl ideálně v jednom sprintu (ideálně za 1–3 dny).

Příliš velkou story: Jako zákazník chci platit kartou lze například rozdělit do menších částí: 1) Jako zákazník chci zadat údaje karty při checkoutu. 2) Jako zákazník chci uložit kartu pro příští nákup. 3) Jako zákazník chci vybrat z uložených karet. 4)Jako zákazník chci smazat uloženou kartu.

Zde je vhodné zmínit pojem Epic – zastřešující téma, které obsahuje více stories a jedná se o komplexnější funkcionalitu.

Akceptační kritéria

Akceptační kritéria definují, kdy je story hotová. Bez nich každý chápe „hotovo“ jinak. Používá se ro ně formát Formát Given-When-Then:

GIVEN [počáteční stav] WHEN [akce uživatele] THEN [očekávaný výsledek]

Příklad pro story „Export objednávek do CSV“:

AC1:
GIVEN jsem na stránce Objednávky
WHEN kliknu na tlačítko „Export CSV“
THEN stáhne se soubor obsahující všechny objednávky z aktuálního filtru

AC2:
GIVEN mám nastavený filtr na „Tento měsíc“
WHEN exportuji CSV
THEN soubor obsahuje pouze objednávky z tohoto měsíce

AC3:
GIVEN nemám žádné objednávky
WHEN kliknu na Export
THEN zobrazí se hláška „Žádné objednávky k exportu“

Časté chyby

Story jako technický úkol

Jako vývojář chci refaktorovat API endpoint – vývojář není uživatel produktu. Toto je technický úkol, ne user story. Buď to formulujte jako skutečnou story s hodnotou pro uživatele, nebo to dejte jako technický task mimo backlog stories.

Řešení místo problému

Jako uživatel chci dropdown s výběrem země -> Jako uživatel chci zadat svou zemi, abych viděl ceny v místní měně. Proč? Možná dropdown není nejlepší řešení. Možná je lepší autocomplete, možná detekce podle IP atd.

Příliš vágní

Jako uživatel chci lepší dashboard -> co je „lepší“? Rychlejší? Hezčí? S více daty? Toto není story, toto je přání.

Příliš velká (epic)

Jako zákazník chci nakupovat v e-shopu -> toto je epic, tedy zastřešující téma, které obsahuje desítky stories. Rozdělte na konkrétní funkce.

Chybí „proč“

Jako uživatel chci filtrovat produkty podle ceny -> jako uživatel s omezeným rozpočtem chci filtrovat produkty podle cenového rozmezí, abych rychle našel produkty, které si mohu dovolit.

Story, task, epic, theme

Hierarchie:

Theme: Zvýšení konverzí
– Epic: Zjednodušení checkoutu
– Story: Checkout na jedné stránce
– Story: Uložení košíku pro nepřihlášené
– Story: Express checkout pro vracející se zákazníky
– Task: Frontend formuláře
– Task: Backend API
– Task: Integrace platební brány

Story mapping

Jde o metodu pro vizualizaci celého produktu a plánování releasů.

Aktivity (co uživatel dělá)

1. Napište hlavní aktivity uživatele (horizontálně)
2. Pod každou aktivitu přidejte stories (vertikálně)
3. Seřaďte stories podle priority (shora dolů)
4. Nakreslete horizontální čáru pro MVP / release

Připraveno pro sprint

Než story vstoupí do sprintu, měla by splňovat kritéria připravenosti:

Hotovo

Kdy je story hotová? Je dobré definovat si, co „hotovo“ znamená:

Refinement

Jde o název pravidelných schůzek, kde tým probírá a zpřesňuje stories před sprintem. PM představí story a kontext, tým se ptá, diskutuje, navrhuje. Dále se upřesní se akceptační kritéria, odhadne se náročnost, případně dochází k restrukturalizaci.

Praktický příklad

Epic: Notifikace o stavu objednávky

Story 1: Email po vytvoření objednávky
──────────────────────────────────────
Jako zákazník, který dokončil objednávku, chci dostat potvrzovací email, abych měl jistotu, že objednávka prošla.

Akceptační kritéria:

• Email se odešle do 1 minuty po vytvoření objednávky
• Email obsahuje: číslo objednávky, seznam položek,
  celkovou cenu, odhadovaný termín doručení
• Email má responzivní design (mobil + desktop)
• Odesílatel je „E-shop objednavky@eshop.cz„

Story 2: Email při odeslání zásilky
───────────────────────────────────
Jako zákazník čekající na zásilku, chci dostat email, když je objednávka odeslána, abych věděl, kdy mohu zásilku očekávat.

Akceptační kritéria:

• Email se odešle, když se stav změní na „Odesláno“
• Email obsahuje: sledovací číslo, odkaz na tracking, jméno dopravce
• Pokud není tracking k dispozici, zobrazí se „Sledování zásilky není dostupné“

Story 3: Push notifikace o doručení
───────────────────────────────────
Jako zákazník s nainstalovanou aplikací, chci dostat push notifikaci při doručení, abych věděl, že si mohu zásilku vyzvednout.

Akceptační kritéria:

• Notifikace se zobrazí na mobilu
• Po kliknutí se otevře detail objednávky v aplikaci
• Uživatel může notifikace vypnout v nastavení

Tipy z praxe

1. Pište stories společně. PM napíše první verzi, tým ji na refinementu zpřesní. Společné pochopení je důležitější než perfektní formulace.
2. Akceptační kritéria pište měřitelně. „Rychlé načítání“ není měřitelné. „Stránka se načte do 2 sekund“ je měřitelné.
3. Nevynechávejte mezní situace. Co se stane, když uživatel nemá internet? Co když zadá špatný formát? Tyto scénáře patří do AK.
4. Používejte příklady. „Export obsahuje sloupce X, Y, Z“ je jasnější než „Export obsahuje relevantní data“.
5. Story není contract. Je to začátek konverzace. Pokud během vývoje zjistíte, že něco nedává smysl, mluvte o tom.

Šablona

## [Název story]

**Jako** [typ uživatele]
**chci** [akce/funkce]
**abych** [důvod/hodnota]

### Acceptance Criteria

1. GIVEN [stav] WHEN [akce] THEN [výsledek]
2. GIVEN [stav] WHEN [akce] THEN [výsledek]
3. [Další kritéria]

### Poznámky
- [Design link]
- [Závislosti]
- [Otevřené otázky]

### Out of Scope
- [Co do této story nepatří]

Zdroje

• User Stories Applied – Mike Cohn
• User Story Mapping – Jeff Patton
• INVEST in Good Stories – Bill Wake