На самом деле люди просто под словом стори поинты то же самое что и многие под словом скрам понимают, отсюда можно любые корреляции сделать.

А программисты потом реально делают так, как написали аналитики из всех отделов? :)

Всегда. Как минимум за конкретный спринт.
Берете количество сделанных пойнтов за спринт, длину спринта в рабочих днях и размер команды.
Перемножаете/делите, получаете кросс-курс одного сторипойнта.
Дальше для каждой задачи/фичи можно пересчитать стоимость в человеко-днях и следущим шагом в деньги через средний ФОТ на члена команды.

Программисты тоже участвуют

Под архитектуру выделяются ресурсы годы базы шина и прочее

человеко-годы 😉

Ой

Ноды

если что-то на что-то перемножить или поделить, то не обязательно результат будет иметь хоть какой-то смысл в этой жизни)

Кстати, может неплохо зайти на ретро для рефлексии "сколько на самом деле стоит перекрасить кнопочку"

Да, про большие решения. Увы, когда вот так расписывают получаются плохо работающие и не поворотливые проекты. Потому что невозможно предугадать все варианты, когда и что должно использоваться и какие параметры должны быть. Где-то важнее отказоустойчивость. Где-то масштабируемость. Где-то консистентность. Где-то заточенность под высокий rps на запись. И.т.д. и.т.п.

И все важные вещи не предугадаешь. В идеале, людям надо дать понимание, как им сделать выбор. И дальше уже пусть люди выбирают.

Спринт прошел, команда получила зп, деньги спонсоров продукта потрачены.
Сделано сколько-то полезного.
Сумма затрат/Объем полезного в сторипойнтах=стоимость сторипойнта.
Человеко-дни аналогично. Просто с ними удобнее в нашем случае, т.к. в дискуссию не вмешиваются конкретные зарплаты, и можно прикинуть на абстрактную команду.

вы сторипоинтами и объем полезности исчисляете?

Так они и выбирают. По САР теореме для СУБД, например. Но из ограниченного набора вариантов
В больших решениях важна "полная стоимость владения" и зоопарк из разных решений может весьма больно стрелять в ногу.
А еще весело когда кто-то выбирает прикольную библиотеку, а у нее лицензия с приколами...

Прикольно, когда у вас уже год две команды на такой библиотеке core-продукта написали, а так-то че прикольного 😄

Естественно. Я про то, что вам не надо в проекте описывать в правила выбора CAP теорему. А вот про лицензии сказать важно

ОК, пусть будет "сколько-то задач удовлетворяет DoD".
Суть не меняется.
Вы можете посчитать удельную стоимость одного вашего сторипойнта в каждом спринте.

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

"СУБД Х не справляется с нагрузкой на запись на требуемых объемах данных. Поэтому выбираем У на основании проведенных пилотных экспериментов. Сайзинг для решения на У нужен вот такой".
А дальше все накручивается вокруг "У" в требуемом сайзинге, с резервированием и балансировкой.

Взято в спринт 10 сторипойнтов (сп)
Завершено в спринте 7 сп, остальное не успели (пусть не начали, для определенности)
Дев тим 6 человек, спринт 1 неделя.

6 человек * 5 рабочих дней = 30 человеко-дней (ч.д.) сожрано за спринт.
30 ч.д. /7 сделанных сп = 4,2857 ч.д. на 1 завершенный сп