User stories a akceptačné kritériá: ako ich písať (s príkladmi)
User story je krátky popis požiadavky z pohľadu používateľa. Nehovorí, ako sa má systém postaviť, ale kto čo potrebuje a prečo. Akceptačné kritériá potom presne určujú, kedy je story hotová. Spolu tvoria základ práce agilných tímov a dobrý most medzi biznisom a vývojom.
Formát user story
Ako [rola] chcem [čo], aby [prečo / prínos].
Príklad: Ako obchodník chcem vidieť históriu komunikácie so zákazníkom na jednom mieste, aby som sa pred stretnutím pripravil za pár minút.
Časť „aby“ je najdôležitejšia. Vysvetľuje hodnotu a pomáha tímu nájsť najlepšie riešenie.
Akceptačné kritériá a formát Given–When–Then
Akceptačné kritériá opisujú overiteľné podmienky. Najčastejšie sa píšu vo formáte:
Za predpokladu, že [východiskový stav], keď [akcia], potom [očakávaný výsledok].
Príklad k story vyššie:
- Za predpokladu, že zákazník má 3 e-maily a 2 stretnutia, keď obchodník otvorí jeho kartu, potom vidí všetkých 5 záznamov zoradených od najnovšieho.
- Za predpokladu, že zákazník nemá žiadnu komunikáciu, keď obchodník otvorí jeho kartu, potom vidí správu „Zatiaľ bez komunikácie“.
Pravidlo INVEST: ako spoznať dobrú story
- Independent – nezávislá od iných stories,
- Negotiable – detaily sa dajú dohodnúť s tímom,
- Valuable – prináša hodnotu používateľovi alebo firme,
- Estimable – tím ju vie odhadnúť,
- Small – zmestí sa do jedného šprintu,
- Testable – dá sa overiť akceptačnými kritériami.
Najčastejšie chyby
- Technická úloha namiesto story. „Vytvoriť tabuľku v databáze“ nie je user story.
- Chýba „prečo“. Bez prínosu sa nedá rozhodnúť o priorite.
- Príliš veľká story (epic). Treba ju rozdeliť na menšie.
- Vágne kritériá. „Musí to byť rýchle“ sa nedá otestovať; „do 2 sekúnd“ áno.
Ukážka: user stories vytvorené v Baaito
Zadanie, ktoré sme Baaito dali:
E-shop s nábytkom chce zákazníkom umožniť sledovať stav objednávky a zmeniť termín doručenia bez volania na zákaznícku linku. Zákazník sa prihlási e-mailom, vidí stav objednávky a môže si vybrať nový termín doručenia z ponúknutých.
Ukážka dokumentu
User Stories & Acceptance Criteria — Sledovanie objednávky a zmena termínu doručenia
Prvé strany skutočného dokumentu, ktorý Baaito vytvoril zo zadania vyššie.
User Stories & Acceptance Criteria — Sledovanie objednávky a zmena termínu doručenia
Účel a rozsah
Tento dokument slúži ako pracovný podklad pre spresňovanie Scrum backlogu a pre definovanie overiteľných akceptačných kritérií pre funkcie e-shopu s nábytkom. Cieľom je umožniť zákazníkovi sledovať stav objednávky a zmeniť termín doručenia bez telefonátu na zákaznícku linku.
Dokument je určený pre produktového vlastníka, vývojový tím, QA a zainteresovaných obchodných používateľov. Zahŕňa podložené potreby zákazníka, používateľské príbehy, kritériá Given-When-Then, predpokladané väzby medzi príbehmi a sledovateľnosť k dostupnému zadaniu.
Zahrnuté sú tieto potreby:
- prihlásenie zákazníka e-mailom,
- zobrazenie stavu objednávky,
- výber nového termínu doručenia z ponúknutých termínov,
- zmena termínu doručenia bez volania na zákaznícku linku.
Technické riešenie, konkrétny rozsah stavov objednávky, pravidlá autentifikácie, platnosť ponúknutých termínov, potvrdenie zmeny, oprávnenia, chybové správanie, závislosti na logistike a integračné rozhrania nie sú v zadaní uvedené. Tieto oblasti sú mimo potvrdeného rozsahu a zostávajú TBD — vyžadujú doplnenie produktových a doménových požiadaviek.
Zdrojové požiadavky a predpoklady
Dostupný zdroj:
- SRC-01 — Zadanie iniciatívy: E-shop s nábytkom chce zákazníkom umožniť sledovať stav objednávky a zmeniť termín doručenia bez volania na zákaznícku linku.
- SRC-02 — Spôsob prístupu: Zákazník sa prihlási e-mailom.
- SRC-03 — Sledovanie objednávky: Po prihlásení zákazník vidí stav objednávky.
- SRC-04 — Zmena termínu: Zákazník si môže vybrať nový termín doručenia z ponúknutých termínov.
Chýbajúce podklady:
- Zdrojové požiadavky, používateľský výskum, doménové pravidlá a produktové rozhodnutia:
TBD— vyžaduje sa schválený zoznam požiadaviek alebo produktový backlog. - Register používateľských príbehov:
TBD— vyžaduje sa schválený register príbehov, priorít, stavov a vlastníkov. - Podrobné používateľské príbehy:
TBD— vyžaduje sa potvrdenie rolí, cieľov, prínosov a rozsahu jednotlivých príbehov. - Akceptačné kritériá:
TBD— vyžaduje sa potvrdené správanie pri úspechu, neúspechu, neplatnom prístupe a nedostupných termínoch. - Identifikátory baseline a verzie zdrojov:
TBD— dostupný zdroj obsahuje iba referenciu[run · v1 · fp 3ad9db61d2894853], nie extrahovaný text.
Predpoklady odvodené priamo zo zadania:
- ASM-01: Používateľom je zákazník e-shopu. Tento predpoklad vychádza z formulácie „zákazník“ v zadaní, ale jeho presný profil je
TBD— vyžaduje sa potvrdenie persony. - ASM-02: Systém poskytuje zákazníkovi stav jeho objednávky po prihlásení e-mailom. Konkrétny mechanizmus prihlásenia a väzba na objednávku sú
TBD. - ASM-03: Systém poskytuje jeden alebo viac ponúknutých termínov doručenia. Zdroj neuvádza, kto termíny poskytuje, podľa akých pravidiel vznikajú ani kedy prestávajú byť dostupné.
- ASM-04: Zmena termínu má prebehnúť samoobslužne bez volania na zákaznícku linku. Potvrdenie úspešnej zmeny, notifikácia a následné zobrazenie zmeneného termínu sú
TBD.
Register používateľských príbehov
| ID používateľského príbehu | Persóna | Potreba | Prínos | Priorita | Zdrojová požiadavka | Stav |
|---|---|---|---|---|---|---|
| US-01 | Zákazník e-shopu | Prihlásiť sa e-mailom a zobraziť stav objednávky | Sledovať stav objednávky bez volania na zákaznícku linku | TBD — vyžaduje sa priorita alebo prioritizačné kritérium | SRC-01, SRC-02, SRC-03 | Návrh na spresnenie |
| US-02 | Zákazník e-shopu | Vybrať nový termín doručenia z ponúknutých termínov | Zmeniť termín doručenia bez volania na zákaznícku linku | TBD — vyžaduje sa priorita alebo prioritizačné kritérium | SRC-01, SRC-04 | Návrh na spresnenie |
Vlastník, stav schválenia, závislosti a ďalšie backlogové atribúty sú TBD — vyžaduje sa schválený backlog a zodpovednosti produktového tímu.
Podrobné používateľské príbehy
US-01 — Zobrazenie stavu objednávky
Používateľský príbeh:
Ako zákazník e-shopu chcem prihlásiť sa e-mailom a vidieť stav svojej objednávky, aby som mohol sledovať objednávku bez volania na zákaznícku linku.
- Zdroj: SRC-01, SRC-02, SRC-03.
- Priorita:
TBD— vyžaduje sa prioritizačné rozhodnutie. - Závislosti: Väzba medzi e-mailom zákazníka a objednávkou, ako aj zdroj údajov o stave objednávky, sú
TBD— vyžaduje sa technická a doménová špecifikácia. - Predpoklad: Zákazník je oprávnený zobraziť stav príslušnej objednávky. Pravidlá oprávnenia sú
TBD. - Poznámka na spresnenie: Je potrebné definovať prípady neúspešného prihlásenia, zákazníka bez priradenej objednávky a rozsah zobrazovaných stavov.
Použitá šablóna: User Stories & Acceptance Criteria
Ako to urobiť rýchlejšie
Opíšte funkciu vlastnými slovami alebo priložte BRD. Baaito z neho pripraví user stories s akceptačnými kritériami vo formáte Given–When–Then, ktoré môžete preniesť do Jiry či Azure DevOps.
Časté otázky
Kto píše user stories? Zvyčajne product owner alebo biznis analytik, ale ideálne v spolupráci s tímom.
Aký je rozdiel medzi user story a požiadavkou v BRD? BRD opisuje ciele a rozsah celého riešenia. User stories ich rozkladajú na malé, priebežne dodávané časti.
Koľko akceptačných kritérií má mať story? Typicky 3 až 7. Ak ich je viac, story je pravdepodobne príliš veľká.