А вы попробуйте не заниматься декомпозицией. Вот совсем не заниматься. Так, на скорую руку прикинули, какие компоненты затронет, и всё. Для сравнительной оценки этого за глаза.

Да
Примерно так

А как же конкретика ?

Тогда могу посоветовать:
1) Распишите внятно фичи/истории, а не просите оценивать разработчиков поэкранно, разработчики только верстаю экран за раз (и то не всегда), а логику пилят сразу на фичу/несколько. Работайте именно с фичами/историями. Их будет гораздо меньше чем экранов и проще оценить
2) Заведите таймер и ограничивайте время на итерацию
3) Готовьте нормальные спеки на задачи и давайте полные вводные на таски, чтобы разрабам не приходилось пол пленнинга выяснять, а что от них надо
4) Определите свой велосити и набирайте ровно в него. Часто пытаются напихать больше
5) Ну и подумайте, правильно ли вы приоретизируете, если у вас столько задач на оценку, что она очень затягивается.

Декомпозиция вам в принципе нужна, потому что у вас нет синьера?

Оставьте это на реализацию. На сравнительную оценку конкретика мало влияет.

Ну и самое главное

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

На сколько эти риски велики? Был ли уже такой опыт?
Если всё-таки ошиблись, то что делали?

Это не повлияет на относительную оценку - у них одинаковые шансы ошибиться на любой сторе

На сколько определена точность? Это нормально для вас, если сдвинитесь на спринт?

Да
Например задачу оцененую на 8 поинтов разраб делал 5 дней ...

Это нормально.
Но как часто такое у вас происходило?

И это такая проблема?

В среднем раз за спринт
Реже два

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

👍

Ну в общем попробую то что вы посоветовали
Спасибо большое коллеги 👍

Я бы рекомендовал вам начинать собирать статистику.
А у вас есть какой-то трекер, где вы фиксируете задачи?

Да
Trello + Corrello
И сам в ручную фиксирую для надёжности