User Story

User Story formát sa používa pre popis biznis požiadaviek produktu. User Story formát dáva tímu informáciu o kontexte. Poskytuje informáciu o tom, kto potrebuje vyriešiť nejaký problém. Prečo. Neposkytuje informáciu ako ho má tím vyriešiť, tu im dáva slobodu a možnosť ukázať svoju expertízu.

Príklad reálnej user story

Formát zápisu je nasledovný:

Ako >kto< potrebujem >čo<, aby >benefit<.

Časť >kto< je popisom používateľa, persony, ktorá bude danú požiadavku používať. Časť >čo< definuje požadovanú funkčnosť.

Časť >benefit< popisuje typicky problém, aktivitu, alebo výhodu, ktorú daný používateľ chce vyriešiť. Túto časť môžete referencovať podľa Value Proposition Canvasu.

User story formát nemusí úplne popisovať požiadavku. Je dôležitejší pre vyvolanie konverzácie a pre ľahšie referencovanie požiadaviek počas plánovania. Ďalšie detaily požiadavky sú zachytené v akceptačných kritériách, priloženej podrobnej analýze, dizajnu, alebo UX návrhu.

Príklady user story

Ako klient poisťovne

potrebujem asistenčnú službu v prípade nehody,

aby som sa vedel ako riešiť problém a zmenšil tak stres.		Ako vodič

si potrebujem jednoducho privolať rýchlu zdravotnú pomoc,

aby som prežil aj v prípade, keď neviem, kde sa presne s autom nachádzam.		Ako obchodník

potrebujem spravovať kontakty klientov,

aby ktokoľvek z firmy vedel s nimi udržiavať komunikáciu.

Dobrá user story by mala spĺňať pravidlo INVEST:

IndependentNezávislá na iných požiadavkách. User story môže rozšíriť existujúcu funkčnosť, no kvôli jej realizácii by sme nemali mať závislosti na iných požidavkch, ktoré by sme kvôli tomu museli zaradiť do sprintu.Na začiatku je to veľmi často ťažké dosiahnuť predovšetkým kvôli nedostatku skúsenosti zo správneho delenia požiadaviek
NegotiableUser story má byť jasná a zrozumiteľná pre všetkých v tíme. Zrozumiteľnosť podporujú predovšetkým akceptačné kritériá, dizajn realizácie a UX dizajn.
ValuableHodnotná. Produktový vlastník by mal vedieť prečo je daná user story potrebná, aký problém rieši a nakoľko je hodnotná.
EstimableOdhadnuteľná. Tím by mal vedieť danú user story odhadnúť. Ak nevie, potom je to indikácia nejasne pripravenej požiadavky. Neskoršia realizácia by znamenala veľké riziko, že tím vytvorí iný výsledok v porovnaní s očakávaním produktového vlastníka a klientov.
SmallMalá, realizovateľná počas jednej iterácie.
TestableOtestovateľná. Story by malo byť možné overiť. Z pohľadu kvality technickej implementácie a aj z pohľadu akceptácie používateľa.

Ďalším pravidlo aplikovaným dobrými produktovými vlastníkmi je YAGNI (You Ain’t Gonna Need It) – nebudeš to potrebovať. Toto pravidlo súvisí s počtom nepoužívaných vlastností. Znamená to, že ak produktového vlasntíka napadne nejaká nová vlastnosť, mal by ju nechať „odležať“. Mal by jej dať čas, aby sa ukázalo, či je skutočne potrebná. Mal by validovať jej potrebu u klientov a až potom ju zaradiť do backlogu.

Vzhľadom na aplikáciu lean pravidla Tak neskoro ako sa dá neodporúčame pripravovať user stories detailne vo väčšom počte. Stačí na najbližší sprint. Zmeny biznisu sú tak časté, že úsilie venované do detailizácii požiadaviek by znamenalo zbytočnú stratu.

Pri písaní user stories na fyzické karty si dohodnite formát takejto karty. Umožní vám to udržať konzistentný a veľmi čitateľný backlog s rýchlou orientáciou.

Stiahnuť prázdne karty pre User Story

Na karte je priestor aj pre priorizačné hodnoty používané pri plánovaní sprintu, resp. produktového inkrementu.

PoložkaŠkála hodnôtPopis
MoSCoW{Must Should Could Won’t}Dôležitosť z pohľadu klienta, používateľa.
Business Value€, $, {0,1/2,1,2,3,5,8,13,20,40,100}Hodnota z pohľadu dodávateľa
Riziko{L,M,H}, {0,1,2,3,4,5,6,7,8,9}Riziko implementácie.
Odhad{0,1/2,1,2,3,5,8,13,20,40,100}Náročnosť, typicky v story pointoch.
Novinky

Naše Agiloviny

Nenechajte si ujsť výber toho najlepšieho z Agile, s čím sa stretli naši mentori. Nielen zo sveta produktov, vývoja, tipov a trikov, ale občas aj humoru. Posielame pravidelne, raz za občas :) #QualityOverQuantity

Posielať na

spracovaním osobných údajov

Ďakujeme