ЗАДАЧА vs ИСТОРИЯ. Виды декомпозици User Story на элементы помельче

Будем различать термины "задача" и "подзадача". Они являются частями истории и не несут ценности сами по себе. "История" и "фича" являются задачами, результатом которых будет ценность - законченная ценность для пользователя. Это может быть функция, какое-то поведение, либо может быть NFR - нефункциональная характеристика, нефункциональные требования.
-----------------
Тренинг и воркшоп User Story Mapping dblinov.com/tr...
Статья о User Story Mapping dblinov.com/bl...
Статья о способах декомпозиции Историй dblinov.com/bl...
Статья с 38 доводами "Почему история должна быть меньше 1 спринта?" здесь dblinov.com/bl...
-----------------
Слово "декомпозиция" используется в нескольких значениях. Первая группа значений - это разделение истории на подзадачи, например, по типам работы (требования, архитектура, дизайн, разработка, тестирование, интеграция, промышленная среда) либо по архитектурным слоям (фронт, миддл, бэк, база).
Другой вариант использования термина "декомпозиция" - это разделение большой истории на маленькие, независимые и умещающиеся в один спринт. При этом первая группа декомпозиции по типам работы, по архитектурным слоям в целом полезна, потому что мы детализируем задачу, уточняем её, остаётся меньше неизвестных, нам более понятно. Такая декомпозиция очень сильно пересекается и соответствует нашему Definition of Done, который перечислен в определении готовности. Однако, не помогает выпускать инкремент каждую операцию, потому что в общем случае любая, например, системный анализ, проектирование или разработка на бэке может занимать более одного спринта.
С другой стороны, разделение большой истории на истории поменьше тоже полезно, тоже помогает уточнить задачу и при этом помогает нам выпускать инкремент каждую итерацию. Потому что, если у нас в спринте хотя бы несколько историй, каждая из которых несёт законченную, завершённую ценность, если хотя бы часть из них мы выполним, то уже в конце спринта будет какой-то результат.