Uživatelský příběh je stručný popis nové funkčnosti produktu nebo jejího vylepšení. Neobsahuje technické řešení, ale odpovídá na otázky týkající se funkčnosti: Kdo je uživatel? Co produkt dělá? A jaký je jeho účel? Uživatelský příběh popisuje produkt v každodenním nebo obchodním jazyce, i když také ukazuje na úkoly Scrum týmu, které mají za cíl zlepšit výkon týmu.
Co jsou uživatelské příběhy? – obsah:
- Úvod
- Uživatelský příběh. Čí příběh to je?
- Jak používat uživatelské příběhy?
- Akceptační kritéria
- Shrnutí
Úvod
Uživatelský příběh je nejběžnější způsob formulace úkolů prováděných Scrum týmem. Jeden uživatelský příběh definuje malou funkčnost produktu. Popisuje nejmenší smysluplný, částečný cíl produktu. Z tohoto důvodu jsou uživatelské příběhy velmi stručné.
Uživatelské příběhy se vytvářejí po celou dobu práce na produktu. Vytvářejí se kontinuálně, od okamžiku, kdy je učiněno rozhodnutí začít pracovat, až po realizaci cíle produktu.
Vytváření uživatelských příběhů je úkol Product Ownera. Na základě rozhovoru se zákazníkem formuluje odpovědi na otázky, které umožňují vytvořit uživatelský příběh a zapisuje je do Product Backlogu. Uživatelské příběhy však odrážejí nejen potřeby zákazníků.
Uživatelský příběh. Čí příběh to je?
Scrum tým vytváří uživatelský příběh, aby definoval potřeby uživatele, a proto je zapsán v obchodním jazyce. Jinými slovy, ukazuje na výhody, které jeho realizace přinese uživateli produktu. V Product Backlogu však mohou být také uživatelské příběhy, které popisují potřeby vývojového týmu, například zlepšení pracovního postupu mezi vývojáři, nebo popisují potřeby Product Ownera, například organizaci Product Backlogu. V takových případech je uživatel v uživatelském příběhu vývojář a Product Owner.
Uživatelský příběh můžete popsat odpovědí na 3W otázky:
- Kdo?
- Provádí co?
- Proč?
Uživatelský příběh je pak obsažen v následující formuli:
Jako [typ uživatele], chci [co chci dělat?] Protože [proč?].
Příklady uživatelských příběhů o funkčnosti online obchodu napsané tímto způsobem jsou ilustrovány v tabulce níže:
Tato formule umožňuje nejen formulovat uživatelský příběh, ale také relativně snadno překládat technický jazyk do obchodního a naopak. Výsledkem je, že jak vývojáři, tak zúčastněné strany jasně vidí cíl a fáze jeho postupu. V samostatném článku v sérii Scrum Guide se také budeme zabývat vytvářením dobrých uživatelských příběhů pomocí metody INVEST.
Jak používat uživatelské příběhy?
Vytvoření schematického uživatelského příběhu je jen začátek. Jsou to signály a výchozí body pro diskuse o problémech a jejich řešeních. Diskuse o uživatelských příbězích probíhá během plánování sprintu, aby se vyjasnilo, které technické problémy vývojový tým přidá do Sprint Backlogu.
Obvykle jsou v fyzickém prostoru uživatelské příběhy napsány na malých barevných kartách, které jsou připevněny na pracovišti. V digitálním prostoru však nejlépe fungují digitální tabule, které sdílí Scrum tým.
Ukládání uživatelských příběhů tímto způsobem má několik výhod, protože:
- Zdůrazňuje autonomii každého uživatelského příběhu – každý má samostatný rámec a může být proveden nezávisle na ostatních
- Zdůrazňuje dynamiku uživatelských příběhů – pořadí jejich realizace je přehodnocováno Scrum týmem a aktuální pořadí realizace je viditelné na tabuli díky fyzickému uspořádání karet s uživatelskými příběhy
- Slouží jako připomínka – díky vizuální reprezentaci uživatelských příběhů má Scrum tým na očích orientační bod, který jim připomíná cíl při vytváření podrobných řešení.
Vývojový tým odhaduje potřebné úsilí k dokončení uživatelského příběhu v dnech, člověk-hodinách nebo Story Points.
Akceptační kritéria
Uživatelský příběh musí mít určitá akceptační kritéria v okamžiku, kdy je přijat k vývoji vývojovým týmem. Akceptační kritéria určují, v jakém okamžiku může být práce na uživatelském příběhu považována za dokončenou.
Tímto způsobem jak klient, tak vývojáři vědí, jak se jejich práce přetaví do obchodní hodnoty. Obvykle je uživatelský příběh považován za dokončený, když uživatel uvedený v něm může provést popsanou akci. Použijte výše uvedený příklad a podívejte se na tento uživatelský příběh s obsahem:
Zákazník může koupit kouzelnou hůlku jedním kliknutím.
Je dokončen, když se na stránce online obchodu objeví funkční tlačítko “Koupit nyní”, které používá výchozí platební a dodací informace pro přihlášeného uživatele.
Shrnutí
Uživatelský příběh je stručný popis nové funkčnosti produktu nebo vylepšení. Slouží jako nejmenší cíl vyjádřený v obchodním jazyce, tedy z pohledu obchodní hodnoty a uživatele. Pomáhá jasně definovat úkol, který má být proveden, stejně jako kritéria pro jeho dokončení.
Pokud se vám náš obsah líbí, připojte se k naší komunitě pracovních včel na Facebooku, Twitteru, LinkedInu, Instagramu, YouTube, Pinterestu.
Caroline Becker
Jako projektová manažerka je Caroline odbornicí na hledání nových metod, jak navrhnout nejlepší pracovní postupy a optimalizovat procesy. Její organizační dovednosti a schopnost pracovat pod časovým tlakem z ní činí nejlepší osobu, která dokáže složité projekty přetavit ve skutečnost.
Scrum Guide:
- Slovník základních pojmů, rolí a představ
- Co je Scrum?
- Hodnoty Scrumu
- Jak implementovat Scrum ve vaší společnosti?
- Scrum tým - co to je a jak to funguje?
- Kdo je Product Owner?
- Nejčastější chyby Product Ownera
- Kdo je Scrum Master?
- Nejčastější chyby Scrum Mastera
- Jaké statistiky a metriky by měl Scrum Master sledovat?
- Vývojový tým ve Scrumu
- Nejčastější chyby vývojářů
- Scrum artefakty
- Škálování Scrumu
- Sprint Backlog
- Co je to Product Backlog?
- Co jsou uživatelské příběhy?
- Vytváření nejlepší uživatelské příběhu s INVEST
- Nejčastější chyby v uživatelských příbězích
- Kritéria přijetí uživatelského příběhu
- Odhad a příběhové body ve Scrumu
- Plánovací poker
- Hra o odhadování týmu
- Definování přírůstku
- Scrum události
- Co je to burndown chart?
- Výhody a nevýhody burndown grafu
- Kanbanové tabule ve Scrumu a Scrumbanu
- Rychlost v Scrum - Rychlost vývojového týmu
- Denní Scrum
- Plánování sprintu
- Sprintová revize
- Co je to Sprint Retrospektiva?
- Běžné chyby během retrospektivy sprintu
- Péče o produktový backlog
- Jak vytvořit a interpretovat burndown chart?