1-1.5 часа

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

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

Простите, но ваше утверждение означает, что ПМ не годится никуда. Не может снять с бизнеса показания, составить грамотные требования, нарезать на юзер стори и подать к столу полуфабрикаты. Сырая задача стоит в 10 раз больше у разрабов, чем разделанная и ошкуренная.

Эээ, при чем тут PM? Я про то, что планирование user story требует техдизайна, оценки осмысленности реализации (обратной связи с PMом), декомпозиции. оценки элементов по декомпозиции и оценки стоимости коммуникаций. Это за пять минут сделать можно, не не надежно и только по "аналогии с уже реализованным".

Позволю высказать мнение: вам не нужны спринты. Воспользуйтесь тем, что предлагает канбан метод.
1) приоритезируйте бэклог
2) декомпозирйте элементы бэклога сверху вниз
3) оцените в попугаях
4) проделывайте с некоторой периодичностью
5) сделали задачку (запрограмировали, оттестировали) - отгружайте.
и будет праздник

И, кстати. сырая обычно стоит (при оценке разработчиками) в 10 раз меньше, чем полностью приготовленная. Так как там появляются corner cases, дополнительные требования и т.п. Про которые PM не думают (так как это не совсем их задача).
Ну, банально "поведение при ошибках" )

+1

Спасибо за совет. Все практически так и работает, кроме пятого пункта, а в четвертом период = 2 недели.

Ну, пятый пункт тут самый важный )

Самое важное: работа это праздник!

все летит в релиз

Если ПМ взаимодействует с архитектором на этапе детализации задач на следующий спринт - готовые задачки наверняка стоят дешевле, чем сырые. Ну это, конечно, мое мнение. Давайте уберем ПМа из уравнения и позволим бизнесу угнетать разрабов напрямую. Я сейчас не о ежечасной смене приоритетов, а о постановке задачи. Продавец путаным образом объясняет в своей системе координат что ему нужно. Согласитесь, если записать  с его слов "как есть" в большинстве случаев задача будет казаться очень дорогой

Я про то, что там много обратных связей - во всей цепочке.
продавец-PM (тут еще бы понять, а что он делает,  у всех разное) - архитектор (тоже не четкая позиция) - лид - программист - девопс - SRE
И от каждого шага может пойти запрос на модификации обратно. Которые плохо предсказуемы и маловыполнимы без большей части реализации.

ну по мне лучше раз в две недели скрещивать пальцы за новый релиз, чем по рандому. Пустоты от перезакладывания всегда можно заполнить багфиксами, или "о Боже!" взять еще задачку, изменив объем спринта

О да! обратная связь выдает в вас месье гурмана ;)

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

ох уж эти обратные связи

мы зовем гостевых звезд (заказчиков) на статусы, если к ним есть вопросы.

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