• Creating stories – Popisujte změnu chování systému, Příliš se nezabývejte o formálním zápisem, ...
• Planning with stories – Používejte hierarchický backlog, Vytvořte si graf stakeholderů, Na začátku milníku si stanovte globální cíle, ...
• Discussing stories – Představujte si, jak výsledek předvádíte; Do diskuze zapojte všechny role; Oddělte byznysové a technické diskuze, ...
• Splitting stories – Zjednodušte výstupy, Zmenšete zákaznický segment, Rozdělte podle kapacity, ...
• Managing iterative delivery – Vyhýbejte se čísleným velikostem pro user stories, Nikdy neříkejte „ne“ – říkejte „ne teď“, Hotové user stories odhoďte, ...

U té poslední, „Hotové user stories odhoďte“, se na chvíli zastavím – je zajímavé, jak snadno k tomu lidé sklouznou. Používat zadání jako dokumentaci je nesmysl i ve waterfallu, a v agile, kde je granularita ještě větší, je to úplná hloupost. Jednoduše proto, že projekty i user stories provádějí iterativní změny, a dobírat se aktuálního stavu procházením historie je jednak extrémně pracné, jednak náchylné na chyby. Autoři radí mít specifikace a testy jako součást kódu, z mojí zkušenosti postačí mít jako definition of done aktualizaci dokumentace (ať už je kdekoliv). K hotovým user stories se pak tým vrací pouze když dohledává, kdy něco měnil a pro koho.

Tohle je jedna z knih, kterou by měl mít product owner u sebe a číst ji pořád dokola, dokud si velkou část tipů nezapamatuje, aby měl z čeho vybírat, nebo dokud je rovnou neuvede do praxe.

Odkazy: