Ну а что вы ожидали. По сути всегда ответ, как пожелаете, а там делаете то что делается. Все, все равно не сделать. Главное угадать/понять что важно, сдать только это, остальные через неделю отвалятся.  Редко когда не отваливаются. Ну а когда не отваливаются, ставится вопрос - вам это или то? Вместе никак. А можно, ну делайте сами, мы посмотрим. Через три дня, а, ну нельзя же. Вот и все.

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

А как выглядит диаграмма навигации?
Структура данных определяется на этапе оценки?

Вроде карты переходов?

на этапе оценки весь проект «прикидывается» на глазок без подробностей, а оценивается эта же работа но точно
чтобы изучить и оценить проект обычно требуется около 1md, иногда и вопросы заказчику позабавить чтобы оценить можно было.

диаграмма навигации - почти что bpmn только по экранам) от какого экрана и по взаимодействию с каким элементом куда пользователь попадает, иногда это нужно иногда нет.

структура данных вообще не всегда аналитиком прорабатывается) но прикинуть в целом можно и оценить сколько потребуется на детальную проработку

да, типа того

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

Насколько точно удаётся спрогнозировать сроки работы аналитиков?

тут вопрос опыта оценки в конкретных условиях, но вообще если отклонения в пределах 20% то это хорошая оценка
если 50% то оценивал новичок, или заказчик трудный, или проект очень объёмный и сложный

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

у нас обычно лид аналитиков оценивает из своего опыта и состава команды, также как оценивается лидом программистов и тестировщиков. к сумме чч или чд прибавляется 10-20% на риски

вопрос еще в загрузке команды, времени переключения контекстов. потому календарные сроки планировать часто даже сложнее, чем трудозатраты))

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

нужно просто планировать не один, а сразу 10 разных сроков и давать им разное P-value

Зачем?

чтобы на вопрос по срокам всегда был однозначный и правдивый ответ

Жирно троллите уважаемый)

со сроком теперь уже практически и не ошибешься - максимум с вероятностью, ну дак а кто это проверит?

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

В принципе, мы часто так делаем. Что вот к этому сроку реально только если всё пройдёт идеально, выдадут тестовые сервера не позднее... выдадут методы не позднее... итп
критерии, почему сроки могут сдвинуться. И некий наиболее вероятный срок, когда ожидаемо будет готово, с учётом рисков