User Story: Способы разделения больших на меньшие

Слово "декомпозиция" используется в нескольких значениях:

разделение истории на подзадачи/subtasks по типам работы (например, так: написать требования, спроектировать решение, создать макет дизайна, написать код и т.д.) или по архитектурным слоям;
разделение большой истории на истории поменьше, независимые, и умещающиеся в один спринт.

Декомпозиции первого типа, конечно же, тоже полезно делать (кстати, в этом помогает Definition of Done), однако это НЕ помогает выпускать инкременты каждую итерацию или чаще.

А зачем нужно, чтобы история умещалась в 1 спринт?

Следование принципу Скрама об инкрементальности. Следование, конечно же, не слепое – у работы инкрементами множество плюсов, 17 штук перечислено здесь.
Банальная работа с риском не успеть вовремя.
А ещё декомпозировать можно даже в ходе спринта, когда понимаете, что не успеете выполнить задачу в текущей формулировке.

А теперь подробнее:

Декомпозция по этапам процесса создания продукта
Декомпозция по слоям архитектуры, платформам, компонентам
Разделение по шагам и ролям бизнес-процесса
Разделение по детальности проработки

Первый тип декомпозиции – на функциональные задачи, на этапы процесса SwD, производства ПО. Оно кажется естественным, потому что сотрудники привыкли к функциональным ролям. Такое деление провоцирует проблемы взаимодействия на стыках. Однако с точки зрения инкрементальности и MVP нам важно, что 1) внутренние отбрасываемые артефакты не нужны клиенту, 2) выполнение части задач не несет ценности. Поэтому такая декомпозиция не помогает создавать инкременты.

Второй тип декомпозиции разделяет характеристику или функцию тоже на подзадачи, sub-tasks, но по архитектурным слоям: подсистемам, платформам, устройствам. И такое деление тоже кажется естественным, потому что отражает внутреннее устройство продукта. Однако эта внутренняя кухня не интересна клиенту. С т.зр. MVP часть этих подзадач можно отрезать, отложить и реализовать позже (отмечено "Да").

Декомпозиция на куски с т.зр. пользователя, называется splitting (потому что можно поделить задачу пополам и сделать только одну часть, а вторую отложить на поздний срок или вообще не делать) или slicing (если изобразить архитектурные слои в виде торта, то вертикально отрезанный кусок приносить небольшую, но полную ценность клиенту).

Разделение истории, splitting, slicing. Важно стараться, чтобы релазовывалось только то, что действительно важно, и не накладывались преувеличенные ограничения вида "это можно сделать только одним куском". Во многих реальных ситуациях это означает, скорее, "это возможно, но лучше сразу сделать вот это и вот это". Из-за желания сделать побольше наперед (big design up front) программисты стремятся сразу спроектировать БД, создать все очевидные атрибуты, словари-справочники, админки и пр. Однако полезно придерживаться

принципа 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 – определению готовности