A UserStory egy lefejlesztendő rendszer-funkcionalitást, vagy felhasználói igényt jelent. A funkció meghatárazásakor a felhasználói szemléletű leírás (Szerepkör -> Cél) széleskörűen elterjedt az agilis projektekben. "Mint felhasználó, szeretnék egy vonatjegyet foglalni Párizsba"

A UserStory-k meghatározásakor gyakran használják a következő szabályokat:

3C
Card, Conversation, Confirmation

INVEST
Independent, Negotiable, Valuable, Estimable, Small enough, Testable

USERVOICE FORMAT
AS A <User Role>
I CAN <Goal>
SO THAT <Business Value>

Így a UserStory-k eredményorientáltak és felhasználócentrikusak.

Minden UserStory a csapat által kerül becslésre, valamint a ProductOwner által priorizálva, továbbá elég kicsinek kell lennie, hogy egy Sprint alatt szállítani lehessen (általában a legkisebb csapatok is minimum 3 UserStory-t szállítanak egy Sprint-ben). Ez szükségszerű ha vizsgálni szeretnénk az értékszállítás, a láthatóság, a rugalmasság, a visszajelzés  és a folyamatos javítás előnyeit.
Egy coach életében gyakran előfordul, hogy segítenie kell a ProductOwner-nek felosztani a UserStory-kat kisebb egységekre.
Itt olvasható 10 stratégia amely hatékonyan segít nagyon UserStory-k felosztásakor:

1. Egy folyamat lépései

A felhasználó egy jól definiált folyamat meghatározott lépéseit hajtja végre. A nagy UserStory ezen lépések - státuszok mentén van felosztva és lépésenként lefejlesztve. Minden lépésnek saját UserStory-ja lesz.

2. Forgatókönyv

Egy forgatókönyv mentén történik a feldarabolás. Az egyik UserStory lehet a sikeres bejárási út, a többi pedig az alternatív bejárások:
Ha x történik, akkor…
Ha .., akkor

3. Forgatókönyv szekvenciája

Sokkal precízebb, ha a UserStory-kat a forgatókönyv specifikus lépéseinek szekvenciája mellet osztjuk fel.

4. Műveletek

A UserStroy-k feldarabolásának egyik legkézenfekvőbb és leggyakoribb módja ha műveletek mentén osztják szét. A CRUD (Create, Retrieve, Update, Delete) funkcionális dekompozícionálás jó példa lehet. Természetesen ezekből csoportokat is lehet képezni (pl. két részre bontva) ha az megfelelőbb.

5. Az adatméret vagy adattípus

Szintén gyakori eset. A nagy UserStory a használt objektumok kezelése mentén lesz felbontva (pl. különböző account type, vagy language message)

6. Input, Output típus vagy Konfiguráció

Adat és adattípus variációk konfigurációk függvényében vagy akár UserInterface esetek konfigurációként értelmezve szintén segíthetnek nagyobb UserStory-k felosztásában.

7. Felhasználó típus vagy szerepkör

A UserStory felosztást a terméket használók személye vagy betöltött szerepköre mentén is elvégezhetjük. Ha a UserVoice formátumot használtuk a Story-k meghatározásánál akkor kézenfekvő és egyszerű lehet ez a fajta megközelítés. Másfelől segíthet a bonyolult UserStory-k vizualizálásában.

8. Ismeret szintje

A szétdarabolás elengedhetetlen feltétele a funkcionalitás mély ismerete. Szétbontható egy nagyobb UserStory jól ismert és ismeretlen részekre. A kevéssé ismert UserStoryk-ra értelemszerűen spike-okat lehet indítani, azaz olyan timebox-olt rövid iterációt, amelynek az outputja a vizsgált ismeretlen időbeli megbecslése.

9. Komplexitás szintje

Például egy UserStrory-t a legegyszerűbb legelemibb funkcióra bontjuk, a többi peddig ettől komplexebb vagy többrészlettel bíró darabba.

10. Minőségi szintek

Teljesítmény, biztonság, használhatóság ezek a nem funkcionális követelmények gyakran hangzanak el egy specifikus UserStory-val kapcsolatban. Ezek az elégedettség fokmérői de ugyanakkor segíthenek a UserStory felbontásban is (pl. 60 másodpercen belül jelenjen meg a képernyőn, kevesebb mint 30 másodpercen benül jelenjen meg a képrenyőn, valós időben jelenjen meg a képernyőn).