User stories a akceptační kritéria: jak je psát (s příklady)
User story je krátký popis požadavku z pohledu uživatele. Neříká, jak se má systém postavit, ale kdo co potřebuje a proč. Akceptační kritéria pak přesně určují, kdy je story hotová. Společně tvoří základ práce agilních týmů a dobrý most mezi byznysem a vývojem.
Formát user story
Jako [role] chci [co], abych [proč / přínos].
Příklad: Jako obchodník chci vidět historii komunikace se zákazníkem na jednom místě, abych se před schůzkou připravil za pár minut.
Část „abych“ je nejdůležitější. Vysvětluje hodnotu a pomáhá týmu najít nejlepší řešení.
Akceptační kritéria a formát Given–When–Then
Akceptační kritéria popisují ověřitelné podmínky. Nejčastěji se píší ve formátu:
Za předpokladu, že [výchozí stav], když [akce], pak [očekávaný výsledek].
Příklad ke story výše:
- Za předpokladu, že zákazník má 3 e-maily a 2 schůzky, když obchodník otevře jeho kartu, pak vidí všech 5 záznamů seřazených od nejnovějšího.
- Za předpokladu, že zákazník nemá žádnou komunikaci, když obchodník otevře jeho kartu, pak vidí zprávu „Zatím bez komunikace“.
Pravidlo INVEST: jak poznat dobrou story
- Independent – nezávislá na jiných stories,
- Negotiable – detaily lze dohodnout s týmem,
- Valuable – přináší hodnotu uživateli nebo firmě,
- Estimable – tým ji umí odhadnout,
- Small – vejde se do jednoho sprintu,
- Testable – lze ji ověřit akceptačními kritérii.
Nejčastější chyby
- Technický úkol místo story. „Vytvořit tabulku v databázi“ není user story.
- Chybí „proč“. Bez přínosu nelze rozhodnout o prioritě.
- Příliš velká story (epic). Je třeba ji rozdělit na menší.
- Vágní kritéria. „Musí to být rychlé“ nelze otestovat; „do 2 sekund“ ano.
Ukázka: user stories vytvořené v Baaito
Zadání, které jsme Baaito dali:
E-shop s nábytkem chce zákazníkům umožnit sledovat stav objednávky a změnit termín doručení bez volání na zákaznickou linku. Zákazník se přihlásí e-mailem, vidí stav objednávky a může si vybrat nový termín doručení z nabídnutých.
Ukázka dokumentu
User Stories & Acceptance Criteria — Sledování objednávky a změna termínu doručení
První strany skutečného dokumentu, který Baaito vytvořil ze zadání výše.
User Stories & Acceptance Criteria — Sledování objednávky a změna termínu doručení
Účel a rozsah
Tento dokument slouží jako podklad pro zpřesňování Scrum backlogu a pro přípravu ověřitelné akceptace funkcí e-shopu s nábytkem. Zaměřuje se na zákazníka, který se přihlásí e-mailem, zobrazí stav objednávky a vybere nový termín doručení z nabídnutých možností.
Dokument zahrnuje:
- zdrojově uvedenou potřebu sledovat stav objednávky;
- zdrojově uvedenou potřebu změnit termín doručení bez volání na zákaznickou linku;
- přihlášení zákazníka e-mailem;
- zobrazení stavu objednávky;
- výběr nového termínu doručení z nabídnutých termínů;
- uživatelské příběhy, akceptační kritéria ve formátu Given–When–Then, závislosti a sledovatelnost.
Podrobné funkční požadavky, pravidla pro přihlášení, způsob identifikace objednávky, seznam stavů objednávky, pravidla nabídky termínů, oprávnění ke změně termínu a chování při chybách nejsou ve vstupu uvedeny. Tyto části jsou TBD — vyžadován schválený zdrojový požadavek nebo produktové rozhodnutí.
Vyloučeny jsou oblasti, které nejsou ve vstupu doloženy, zejména správa objednávky pracovníkem e-shopu, změna jiných údajů objednávky, platby, reklamace, notifikace a integrace s dopravcem. Jejich zahrnutí by vyžadovalo samostatný zdrojový požadavek.
Zdrojové požadavky a předpoklady
Dostupné zdrojové podklady
- SR-001 — Sledování stavu objednávky: E-shop s nábytkem chce zákazníkům umožnit sledovat stav objednávky. Zdroj: vstup pro účel a rozsah.
- SR-002 — Změna termínu doručení: Zákazník může změnit termín doručení bez volání na zákaznickou linku. Zdroj: vstup pro účel a rozsah.
- SR-003 — Přihlášení e-mailem: Zákazník se přihlásí e-mailem. Zdroj: vstup pro účel a rozsah.
- SR-004 — Výběr nabídnutého termínu: Zákazník si může vybrat nový termín doručení z nabídnutých termínů. Zdroj: vstup pro účel a rozsah.
Předpoklady a omezení
- Role zákazníka je podporována zdrojovým zadáním.
- Zobrazení stavu se týká objednávky zákazníka; způsob vazby mezi zákazníkem a objednávkou je TBD — vyžadováno upřesnění identifikace a oprávnění k objednávce.
- Nabídka nových termínů existuje, ale její zdroj, dostupnost, platnost a pravidla výběru jsou TBD — vyžadováno produktové nebo doménové rozhodnutí.
- Přihlášení e-mailem je uvedeno, ale metoda ověření e-mailu, bezpečnostní pravidla a chování při neúspěšném přihlášení jsou TBD — vyžadovány funkční a bezpečnostní požadavky.
- Vstupy pro registr, podrobné uživatelské příběhy a akceptační kritéria chybí. Priorita, stav, vlastník, závislosti, testovací důkazy a validační výsledky jsou proto TBD — vyžadován schválený backlog a testovací podklad.
Registr uživatelských příběhů
| ID uživatelského příběhu | Persona | Potřeba | Přínos | Priorita | Zdrojový požadavek | Stav |
|---|---|---|---|---|---|---|
| US-001 | Zákazník e-shopu | Přihlásit se e-mailem a zobrazit stav své objednávky | Sledovat stav objednávky bez volání na zákaznickou linku | TBD — vyžadováno prioritizační rozhodnutí | SR-001, SR-003 | TBD — vyžadován stav backlogové položky |
| US-002 | Zákazník e-shopu | Vybrat nový termín doručení z nabídnutých termínů | Změnit termín doručení bez volání na zákaznickou linku | TBD — vyžadováno prioritizační rozhodnutí | SR-002, SR-004 | TBD — vyžadován stav backlogové položky |
Vlastník příběhů a konkrétní závislosti nejsou ve vstupu uvedeny: TBD — vyžadován vlastník produktu nebo doménový vlastník a schválený backlog.
Podrobné uživatelské příběhy
US-001 — Sledování stavu objednávky
Jako zákazník e-shopu, chci se přihlásit e-mailem a zobrazit stav své objednávky, abych mohl sledovat stav objednávky bez volání na zákaznickou linku.
- Zdroj: SR-001, SR-003; vstup pro účel a rozsah.
- Priorita: TBD — vyžadováno prioritizační rozhodnutí.
- Závislosti: Identifikace zákazníka a jeho objednávky, mechanismus přihlášení a zdroj aktuálního stavu objednávky jsou TBD — vyžadována specifikace závislostí.
- Předpoklady: Zákazník má e-mailovou identitu použitelnou pro přihlášení; způsob ověření není uveden.
- Poznámka ke zpřesnění: Je třeba doplnit pravidla přihlášení, vazbu na objednávku, definici zobrazovaných stavů a očekávané chování při neúspěšném přihlášení.
US-002 — Změna termínu doručení
Jako zákazník e-shopu, chci vybrat nový termín doručení z nabídnutých termínů, abych mohl změnit termín doručení bez volání na zákaznickou linku.
Použitá šablona: User Stories & Acceptance Criteria
Jak to udělat rychleji
Popište funkci vlastními slovy nebo přiložte BRD. Baaito z něj připraví user stories s akceptačními kritérii ve formátu Given–When–Then, které můžete přenést do Jiry či Azure DevOps.
Časté otázky
Kdo píše user stories? Obvykle product owner nebo business analytik, ideálně ve spolupráci s týmem.
Jaký je rozdíl mezi user story a požadavkem v BRD? BRD popisuje cíle a rozsah celého řešení. User stories je rozkládají na malé, průběžně dodávané části.
Kolik akceptačních kritérií má mít story? Typicky 3 až 7. Pokud jich je víc, story je pravděpodobně příliš velká.