Пожертвовать производительностью при декомпозиции User Story? - Это ведь костыль! Разве нет?

Вы предлагаете начать с создания функционала, не обращая внимания на производительность. Но что, если мы добавим эту функцию в продакшн и ее производительность не будет справляться с нагрузкой?
------------------
Тренинг и воркшоп User Story Mapping dblinov.com/tr...
Статья о User Story Mapping dblinov.com/bl...
Статья о способах декомпозиции Историй dblinov.com/bl...
Статья с 38 доводами "Почему история должна быть меньше 1 спринта?" здесь dblinov.com/bl...
-----------------
Хороший вопрос. Здесь я предлагаю вернуться к вопросу о том, что для нас является самым главным риском. Если самым главным риском является нагрузка, то мы ожидаем большое количество пользователей, и есть риск того, что система упадет. В этом случае мы сфокусировано занимаемся работой по производительности и выносим ее на передний план. Однако, если производительность не является основным риском и мы не ожидаем большого количества пользователей, мы откладываем ее в сторону на всякий случай. Мы можем предостеречься такой ситуации и вывести новый функционал для ограниченной группы лиц, на лояльных клиентов и пользователей.