Как писать User Stories
User story - это то, как ваш пользователь должен взаимодействовать с вашим продуктом. Это не технические требования.
1. На выполнение истории не больше 1 итерации, иначе нужно разбить

2. Если какую-то из трех частей можно убрать, то она бесполезна:
- Актор (один) - сделать подгруппы и под них писать истории (персоны)
- Действие (одно) - писать нужно ЧТО делает пользователь, а не КАК. Это важно.
- Ценность (одна) - Не обязательно писать "чтобы". Можно сделать быстрее: щас 60 секунд, должно быть 15 секунд. Ценность должна линковаться с целью продукта. Используйте "Impact map".

3. Каждую юсторию можно оценить по критериям «INVEST»:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration;
- Valuable.
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria;

4. Советы к написанию user stories:
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать
- Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна помещаться в итерацию.

Summary: юстории помогут вам более чётко понимать зачем вы делаете ту или иную фичу, потому что ваш продукт должен решать пользовательскую задачу или проблему. Выработать US можно с помощью брейншторма или CJM.
#product_dump @pm_dump