O tom jak správně psát user story byly napsány celé knihy. Přidám pár svých postřehů.

Představte si situaci, která bývá celkem častá – máte US, kterou lze rozdělit na více samostatných US, ale spolu s první částí je potřeba vyvinout základ, který sám o sobě představuje jistou pracnost. Má smysl uvádět tento základ jako samostatnou US nebo má být přidružen k některé z dalších stories? Jaký je nejvhodnější přístup?

Proč dělit user stories na menší

Obecně platí, že je vhodné dělit US na co nejmenší smysluplné části, protože tak lze lépe user stories lépe plánovat, paralelizovat práci vývojářů a také sledovat průběh sprintu.

Představte si, že máte požadavek, který zní:

  • Jako zákazník chci mít možnost vybrat doručovací metodu Česká pošta, Kurýrní přeprava a DPD, protože zákazník má různé preference přepravních společností.

Celkové náklady na realizaci této User story budou 5 story pointů. Z toho 2 SP připadají na základní funkční rámec, po 1 SP pak připadá na každou z doručovacích metod.

Klasické dělení aneb netestovatelný základ funkcionality

Pokud tuto US rozdělíme na následující 4 US, budeme se potýkat s problémy:

  • 1. US – funkční rámec doručovacích metod – 2 SP,
  • 2. US – zákazník může vybrat doručovací metodu Česká pošta – 1 SP,
  • 3. US – zákazník může vybrat doručovací metodu Kurýrní přeprava – 1 SP,
  • 4. US – zákazník může vybrat doručovací metodu DPD – 1 SP.

Naším problémem v tomto případě bude, že první US není testovatelná, tudíž podle SCRUM metodiky by neměla být zaplánovaná.

Lepší dělení user story

Lepší rozdělení tedy je:

  • 1. US – zákazník může vybrat jednu z doručovacích metod – 3 SP,
  • 2. US – zákazník může vybrat jednu ze dvou zbývajících doručovacích metod – 2 SP.

Která z doručovacích metod je preferovaná a zda dvě zbývající doručovací metody budou realizovány v jedné user story nebo ve dvou samostatných, to už je na produktovém vlastníkovi.

Zároveň se jedná o jednu ze situací, kdy musíme akceptovat, že druhá US sice může být vyvinuta, ale není samostatně testovatelná, alespoň z pohledu koncového uživatele. Plyne z toho na první pohled neflexibilní preference pořadí realizace US tak, aby dávaly smysl. Nicméně jedná se o preferenci, kterou bude řídit produktový vlastník, který určil, že v rámci první US se realizuje pro něj nejvíce hodnotná doručovací metodu nebo naopak její výběr nechal na vývojáři – podle formulace zvolené v US.