Príklad: Keď produktový vlastník chce záložku. Vyvarujte sa chýb pri písaní user story

Ako správne napísať požiadavku vo formáte User story

Pred niekoľkými rokmi spropagoval Mike Cohn user story formát požiadaviek. Odvtedy sa každá požiadavka zvykne v Scrum označovať za User story. Často aj keď ňou nie je. Ba ani vtedy, keď je napísaná v tomto formáte.

Príbeh používateľa

Formát User story je jednoduchý.

Ako niekto

chcem niečo,

aby som mal hodnotu.

Abstraktné, že? Práve takto to má byť:

1. Vývojárom dáva slobodu povedať ako.
2. Vývojárom dáva zodpovednosť povedať ako.
3. Musí byť jasné kto bude požiadavku používať. Ak to nie je jasné a nevyvrátiteľné, tak požiadavka môže mať cieľovú skupinu, ktorá ju aj skutočne bude používať. Ktorá ju zaplatí.
4. Musí byť jasné aký problém požiadavka rieši. Nie ako má problém riešiť. Toto nech povedia vývojári, sú predsa inžinieri. Spôsobov riešenia môže byť viacero. Od najrýchlejšieho, najlacnejšieho, až po komplexný scenár pripravený aj na dopad meteoritu.
5. Musí byť jasný zmysel, job, pain, resp. gain, ktorý implementovaná požiadavka prinesie.

Ak nemáte odpoveď na 3 časti vety, nemáte požiadavku. Nemáte ju prečo robiť.

Pozrime sa na príklady z reálneho zivota

Ako používateľ

chcem záložku s fotkami,

aby som si ich mohol prezerať.

Keď pripomienkujem túto story, premýšľam:

1. Každý používateľ?
2. Registrovaný aj neregistrovaný?
3. Platiaci?

Po debate s tímom zisťujeme, že iba platiaci a prihlásený, a teda samozrejme registrovaný používateľ.

Ako prihlásený platiaci používateľ

chcem záložku s fotkami,

aby som si ich mohol prezerať.

Prečo je dôležité vedieť kto?

1. Lebo vývojár vie, že budú potrebné nejaké autorizácie.
2. Lebo UX dizajnér vie, že  možno treba zobraziť zámok pre ľudí, ktorí nemajú zaplatený produkt.
3. Lebo marketing vie pre koho pripraviť kampane.
4. Lebo sales vie koho osloviť a na aký problém cieliť.

Teraz je na rade čo

… Chcem záložku s fotkami…

Fakt záložku? Prečo to vraví produktový vlastník? Veď má UX dizajnéra v tíme, on je expert. Takže aký problém človek rieši záložkou? Prečo ju potrebuje?

1. Chce publikovať svoje fotky.
2. Chce so známymi zdieľať momentky svojho života. Hmm, toto je už dosť vágne, moment môže byť aj nejaký text popisujú životnú situáciu.
3. Chce vidieť fotografie známych.

Počkať! Prvé dve sú o zdieľaní, posledná o prezeraní. Dve rôzne potreby. A máme teda dve rôzne User stories!

Poďme sa ďalej vŕtať v tej o zdieľaní fotografie.

Ako prihlásený platiaci používateľ

chcem zverejniť svoje fotografie,

aby som si ich mohol prezerať.

Ako by sme mohli vetu zjednodušiť?

Čo je v nej zbytočné, bez dodatočnej informačnej hodnoty? Slovo svoje. Ako bude systém vedieť, ktoré fotografia sú „svoje“? Možno to Product owner fakt chce, ale to už sa bavíme o machine learning a rozpoznávaní ľudí vo fotografiách. Je to tak? Dajme tomu, že nie, dajme slovo svoje radšej preč.

Ako prihlásený platiaci používateľ

chcem zverejniť fotografie,

aby som si ich mohol prezerať.

Čo je hodnotou?

A teraz k poslednej časti vety. Jediný dôvod je prezeranie? Prečo ich chce používateľ prezerať? Hmm, aby známi mali o mne informácie čo zažívam. A prečo ich potrebujú? Hmm, aby zostali so mnou v „kontakte“ aspoň virtuálne.

Ako prihlásený platiaci používateľ

chcem zverejniť fotografie,

aby  priatelia so mnou ostali v osobnejšom kontakte.

Ak by sme sa opäť spýtali prečo by priatelia chceli ostať v osobnejšom kontakte, došli by sme k veľmi vagnej príčine. Takže to nateraz stačí.

Na záver

• Pre vyhľadanie správnych výrazov používajte 5 prečo.
• Odstráňte optické šumy, zbytočné slovíčka, ktoré nepridávajú žiadnu významnú informačnú hodnotu.
• Skúste nájsť používateľa adresnejšie. Najhoršie je „používateľ“. Nezabúdajte, že to nemá byť developer, manažér, Scrummaster, Product owner pokiaľ vyvíjaný systém nie je pre nich.
• Pozor na veľké zovšeobecnenie.
• Celková user story by mala byť úplne realizovateľná počas 3-5 dní. S testami, dokumentáciou atď. Ak je väčšia, skúste ju rozdeliť na menšie tak, aby to stále mali zmysel pre používateľa.
• Validujte používateľa, potrebu a príčiny pomocou value proposition canvasu. Ak vám v canvase niečo chýba, požiadavka je asi zbytočná. Menej je viac!
• Vyjdite von k používateľom a preverte si či ich takýto problém trápi. Lekcia mnohých Startup Weekends.

Máte nejaký svoj príklad, na ktorom sa chcete naučiť písať user stories? Prineste si ich na náš nový workshop User Story – tvoríme a píšeme požiadavky agilne.