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

Смотря о каком бизнесе мы говорим. Если у клиента нет стратегического планирования на ближайший год-пять-семь, то скорее всего надо будет на позавчера. Тогда мы смотрим какой скоуп минимально нужно и можно сделать, чтобы он был жизнеспособным. Это стартовые условия.
При этом есть клиенты, которые планируют заранее, и у которых есть дедлайн: до какой даты мы должны выпустить продукт, который позволит быть конкурентноспособным на рынке. Этот продукт может быть не идеальным, но удовлетворяющим требования пользователей. В этом плане мне очень нравится книга «Психбольница в руках пациента».

Спасибо! :)

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

Мне кажется, вы пропустили пункт о расчете длительности проекта.

Я рада, что у вас есть такой опыт.
Однако не все проекты такие.

Все верно:
Иногда мы делаем оценки на хайлевел (L0), чтобы выбрать те проекты, с которыми будем работать в этом году. А потом, когда выставлены приоритеты, мы делаем детальные оценки.

Любопытный момент: а почему нефункциональные требования не прояснили на старте?

У меня есть опыт успешного завершения вотерфольных проектов длительностью в год: в срок, в бюджет, и в скоуп. ПОэтому все зависит от уровня детализации, количества неизвестных \ неучтенных факторов, и просчетов зависимостей.

Ну почему же везде? Я работаю и с вотерфол проектами.
Многие мои клиенты работают по вотерфол-аджайл. Т.е. сначала делается оценка по вотерфол проекту, но потом работаем «по скрам». И от того, как мы оценим проект в начале, будет зависеть успеем ли мы вообще в дедлайн, с учетом меняющегося скоупа. Тоже интересный опыт :)

Согласна :) И при этом бывают кейсы, когда клиент заявляет о необходимости реализовать весь скоуп и просит просчитать время, а уже только потом появляется дедлайн. И тогда мы возвращаемся к золотому треугольнику и обсуждаем что будет меняться при изменении времени: бюджет или скоуп работ.

А почему вы считаете что эти вещи не связаны? Если мы говорим о подписании контракта, у нас уже есть готовая сумма, расчитанная на основании оценки проекта, подобранной команды (которая влияет на итоговую длительность проекта), и рейтов.
Нередкие случаи, что команда готовит эстимейты под T&M model, а потом не успеваем в заявленные сроки. И желание клиента подписать фикс прайс проект — не редкость. Поэтому когда мы учавствуем в тендере — желательно быть уверенными в своих оценках.