100% agree

Задачу декомпозирует РП + аналитик. Далее скоуп верефицирукт команда на статусе по погружению в проект. Обьем задач(скоуп) на 200-300 часов разработки.

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

В результате
«Забыли, а вот еще надо сделать». «А вот мы тут не посмотрели и пожтому придется еще несколько классов перепилмвать, а это + 30 чч». «Ну я думал что так, получилось больше».

Можно работать внутри по скраму при внешнем фикспрайсе. Есть такие кейсы...

Такое на статусе по погружение рассказываю.

Аналитик в процессе разработки верифицирует результат разработки.

Перед передачей разработки в qa проводится командная приемка. Аналитик+тест+разработчик. Прогоняются сценарии и вот тут-то все и выясняется:)

А все-таки характер ПО позволяет резать работу разрабов не на куски 200-300 часов, а раз в 10 меньше?
Архитектура системы это позволяет? Ну там микросервисы, внутренние API, смарт-заглушки и прочее?
Ну и хоть какие-то элементы DevOps есть?

200-300 это общий скоуп. Режем на куски от 3 до 50 чч.

Стараемся задачи декомпозировать на 8 чч

Не поможет декомпозировать только задачи разрабов на вменяемые куски. Если эти куски нельзя «собрать, оттестировать, показать пользователю». То есть вам нужно научится работу разработчиков релизить часто. Хотя бы релизить внутрь - для нужд QA, для нужд оценки реального прогресса и «проверить что ничего не забыли».

Возможно лучше делать фокус и инвестиции не в прогнозирование/планирование/оценку, а в правильную архитектуру и производственный процесс, дающие возможность «быстро сделать» и «быстро проверить».

«Ошибайся быстро, ошибайся безопасно» - вот это все.

Анекдот вспомнился про «оценить за сколько разгрузишь машину»

Какая детализация, кто делал постановку задачи, как принимается результат. Ничего не понятно.
Вы, как ПМ начните с детализации задачи.  Не смотрите на цифру, а сразу задайте вопрос, как эта цифра получилась. Оценка должна быть в IT не более 24 часов, если больше- требуйте детализацию

Вполне нормальный скоуп для оценки. Тем более, если Вы погружаете команду в суть бизнес задачи. Устанавливайте ответствееность и мотивационную привязку. Мотивация совершенно не обязательно чисто денежная. Что-то же хотят разрабы кроме денег.

Старое доброе правило: пакет работ должен подчиняться правилу 8/80, лучше 8/40

Выше ответил про детализацию)))

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

И что разработчики на статусе говорят про задачи на 8 часов?

Пока не пнешь - не поедит. Вот что показывают. Т.е. постоянно нужно по реестру вопоосов прогонять. Вопросы копят, и жлут когда спросят(не инициаьивны). Есть некоторые вещи не очивидные,когда выявляется, что под маленькой задачей оказывается полсистемы нужно перепилить. На вопрос почему на этапе оценки это не проявилось - 🤷‍♂️незнаю .

Складывается впечатление, что нужно проработать формат сбора статусов

Ну явно девопс при таком отношении команды не зайдет. Так что инкрементная модель, как описано, выглядит разумно.

Есть ли в команде технологический лидер, который имеет понимание, что происходит и который проверяет декомпозицию и оценку задач исполнителями и который мотивирован на успех проекта и который понимает, что следует перепиливать, а что не следует? Eсли вопросы не задают, пытаясь проблемы замести под ковер, тогда индивидуально работать с каждым, пытаясь разговорить, то есть каждый рабочий день индивидуально разговаривать с каждым исполнителем. Как правило, это срабатывает, но побегать придется, да. " На вопрос почему на этапе оценки это не проявилось - 🤷‍♂️незнаю" - Тут лучше задать вопрос - как избежать перепиливания половины системы, какие обходные решения возможны? И еще - если так промахнулись на этапе выявления и оценки задач, то уже не стоит верить заявлениям тех же людей о необходимости перепиливания половины системы.

"когда выявляется, что под маленькой задачей оказывается полсистемы нужно перепилить" - С точки зрения системного анализа звучит не правдоподобно. Что по этому поводу высказывает системный архитектор, и имеется ли в проекте таковой?