Scrum Guide | 21. Chyby v používateľských príbehoch

Užívateľské príbehy popisujú, ako nová funkčnosť produktu funguje v každodennom alebo obchodnom jazyku. Ich príprava však vyžaduje veľa času, úsilia a premýšľania. V dnešnom príspevku poukazujeme na najčastejšie chyby v užívateľských príbehoch a navrhujeme, ako sa s nimi vysporiadať.

Najčastejšie chyby v užívateľských príbehoch – obsah:

1. Úvod
2. Problémy s 3W
3. Problémy s 3C
4. Chyby v užívateľských príbehoch – Zhrnutie

Úvod

Užívateľský príbeh môže byť skvelým nástrojom na motivovanie tímu, aby navrhoval nové riešenia problémov z pohľadu používateľa. Písali sme o tom, čo je užívateľský príbeh v samostatnom príspevku. A v tomto článku sme predstavili INVEST, čo je populárna metóda písania dobrých užívateľských príbehov. Dnes sa zameriame na chyby v užívateľských príbehoch.

Problémy s 3W

Správny užívateľský príbeh odpovedá na otázky:

• Kto? (Kto je cieľový používateľ produktu?)
• Čo? (Aké schopnosti má produkt a čo môže robiť?)
• Prečo? (Aký účel to slúži?)

Problémy však môžu sprevádzať odpovede na každú z týchto otázok. Najmenej častým problémom je pochybnosť o tom, čo by sa malo zmeniť v produkte v reakcii na potreby zákazníka. Preto sa zameriame na problémy týkajúce sa Kto? a Prečo?

Kto – užívateľská persona

Jednou z najčastejších chýb pri vytváraní užívateľských príbehov je nedostatočne presná odpoveď na otázku: pre koho? Inými slovami, kto je používateľ, pre ktorého je plánovaná zmena určená?

Často nie je dostatočná generická odpoveď, ktorá poukazuje na Zákazníka alebo Konečného používateľa ako príjemcu zmeny. Riešením tohto problému je predstaviť si príjemcu ako konkrétnu personu. Persona je modelový obraz cieľového zákazníka. Inými slovami, persona je reprezentácia osoby, ktorá bude produkt používať konkrétnym spôsobom.

Po analýze vášho užívateľského príbehu môžete zistiť, že rozpráva príbehy rôznych ľudí súčasne. Ak je veľa cieľových používateľov, stojí za to zvážiť rozdelenie užívateľského príbehu na menšie fragmenty, aby sa predišlo protichodným, vzájomne sa vylučujúcim alebo jednoducho neefektívnym akciám.

Prečo? – zle definovaný cieľ

Niekedy sa posledná časť užívateľského príbehu stáva zdrojom problémov. Mala by špecifikovať obchodnú hodnotu zmien, ktoré sa vykonávajú počas realizácie užívateľského príbehu. Pozrite sa na príklad chýb v užívateľských príbehoch, kde popis dodatočnej funkčnosti nahrádza cieľ:

Ako zákazník chcem kúpiť čarovnú paličku jedným kliknutím, pretože chcem kúpiť lietajúci koberec budúci týždeň.

Namiesto toho, aby poskytol dôvod na kúpu čarovnej paličky, tento užívateľský príbeh pridáva ďalšiu položku na nákupný zoznam potenciálneho zákazníka. Preto pri príprave užívateľského príbehu nezabudnite na dôvody na zmeny vo funkčnosti produktu.

Problémy s 3C

Proces práce s užívateľskými príbehmi môžeme rozdeliť do troch fáz nazývaných 3Cs:

• Karta – Karta, na ktorej je uložený užívateľský príbeh
• Konverzácia – Konverzácia v rámci Scrum tímu o karte užívateľského príbehu
• Potvrdenie – definovanie akceptačných kritérií potvrdzujúcich, že úloha bola dokončená

Chyby sa môžu vyskytnúť v ktorejkoľvek z týchto fáz, čo popisujeme nižšie.

Karta

Pamäťová karta, ktorá uchováva užívateľský príbeh, má obmedzenú kapacitu. Preto sa najčastejšie problémy týkajú dĺžky a objemu užívateľského príbehu. Užívateľský príbeh potrebuje koherenciu a žiadne zbytočné omáčky, ako sa hovorí, do takej presnej miery, že každé slovo sa počíta.

To je preto, že problém karty užívateľského príbehu má dve dimenzie. Jedna je spôsob, akým je formulovaná: stručne a obsahujúca nevyhnutné minimum výčtu. Druhá je skutočná veľkosť užívateľského príbehu. Jedna všeobecná veta môže vyjadriť obrovské množstvo úloh, ktoré nemožno dokončiť počas jedného Sprintu.

Konverzácia

Jednoslovné formulovanie užívateľského príbehu je východiskovým bodom pre konverzáciu s vývojovým tímom. Preto je nesprávne považovať ho za popis úlohy na vykonanie. Znefunkčňuje to možnosť rokovaní a diskusií o rôznych spôsoboch jeho implementácie. Užívateľský príbeh by nemal byť považovaný za popis požiadaviek na novú funkčnosť produktu, je to skôr pozvanie na začatie konverzácie o konkrétnych technických riešeniach, ktoré povedú k realizácii obchodnej hodnoty definovanej užívateľským príbehom.

Potvrdenie

O akceptačných kritériách, ktoré musia byť definované pre každý užívateľský príbeh, sme podrobne písali v texte popisujúcom čo je užívateľský príbeh. Jednou z bežných chýb je však nedostatok nejednoznačnosti výkonových kritérií.

Dobré napísaný užívateľský príbeh obsahuje popis situácie, v ktorej je implementovaný. Jeho testom je, že používateľ využíva novú funkčnosť vytvorenú vývojovým tímom.

Užitočným nástrojom na validáciu užívateľského príbehu je vyvinúť akceptačný test. To je zvyčajne na druhej strane karty obsahujúcej užívateľský príbeh.

Chyby v užívateľských príbehoch – Zhrnutie

Pri príprave a aplikácii užívateľských príbehov stojí za to dodržiavať nasledujúce pravidlá:

• Presne identifikujte užívateľa ovplyvneného zmenou
• Jasne definujte účel budovania novej funkčnosti produktu
• Udržujte jeho objem čo najkratší
• Považujte užívateľský príbeh za východiskový bod pre diskusie o riešeniach s vývojovým tímom
• Stanovte jasné pravidlá pre akceptáciu

Ak sa vám náš obsah páči, pridajte sa k našej komunite usilovných včiel na Facebooku, Twitteri, LinkedIn, Instagrame, YouTube, Pinterest.