- разделение истории на подзадачи/subtasks по типам работы (например, так: написать требования, спроектировать решение, создать макет дизайна, написать код и т.д.) или по архитектурным слоям;
- разделение большой истории на истории поменьше, независимые, и умещающиеся в один спринт.
Декомпозиции первого типа, конечно же, тоже полезно делать (кстати, в этом помогает Definition of Done), однако это НЕ помогает выпускать инкременты каждую итерацию или чаще.
А зачем нужно, чтобы история умещалась в 1 спринт?
- Следование принципу Скрама об инкрементальности. Следование, конечно же, не слепое – у работы инкрементами множество плюсов, 17 штук перечислено здесь.
- Банальная работа с риском не успеть вовремя.
- А ещё декомпозировать можно даже в ходе спринта, когда понимаете, что не успеете выполнить задачу в текущей формулировке.
А теперь подробнее:
- Декомпозция по этапам процесса создания продукта
- Декомпозция по слоям архитектуры, платформам, компонентам
- Разделение по шагам и ролям бизнес-процесса
- Разделение по детальности проработки




- принципа YAGNI (you aren’t gonna need it), поскольку вам это и правда, возможно, не понадобится – каждый MVP нуждается в проверке потребности со стороны клиентов, и
- принципа KISS (keep it sweet and simple) – для частого выпуска инкрементов они должны быть мельче.

Картинка ниже содержит все способы и текст с комментариями. Скачивайте и пользуйтесь ;)

Другие статьи о User story:
- User Story – история пользователя
- Хорошие User Story соответствуют критериям INVEST
- User Story: Способы разделения больших на меньшие
- Для упорядочивания и планирования историй пользователей широко применяется User Story Map – карта пользовательских историй
- В конце спринта (по Скраму) история, как и любой другой элемент бэклога, должна соответствовать Definition of Done – определению готовности