Скрам как фреймворк, как его воспринимают в большинстве мест где я работал со скрамом - это следующие шаги:
* Придумали, что хотим сделать
* Обсудили что хотим сделать
* Дождались следующего спринта (SIC!)
* Положили в бэклог спринта
* Сделали в спринте (или не сделали - тут как карта ляжет)
* Обсудили на ретро что-нибудь
* Задеплоили
* Устроили демо для клиента
* Поправили баги. Нет, не в этом спринте, в следующем, потому что этот уже распланирован.

итого 5-6 спринтов, чтобы докатить один кусок работы.

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

* Придумали что хочется сделать
* Дождались, когда в очереди входящих запросов попустело
* Обсудили, что хочется сделать
* Сделали
* Задеплоили
* Устроили демо для клиента
* Поправили баги.
Все каденции по планированию на основе заполненности горячей очереди задач, деплой по готовности.
В итоге с 1-2 "спринтами" на задачу одновременно приходилось помнить только о паре текущих задач и об одной следующей.

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

Ну тот же покер планирования. Он не основан на данных, он основан тех не вполне осознаваемых нейронных связях, который просто выталкивают на поверхность 8sp!

спустя год споров о том, "что такое сторипоинт", возможно :)

спустя год споров о том, "что такое сторипоинт", возможно :)

Зачем ждать конца спринта для деплоя?

Потомучто есть устоявшееся мнение что это снижает издержки и повышает предсказуемость. Что я могу сказать еще?

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

просто концепция сторипойнта настолько проста, что надо ее обсуждать год :)
другое дело час — слишком сложно и плохо!

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

вобщем сторипоинты это нифига не просто.

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

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

вобщем сторипоинты это нифига не просто.

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

а зачем привязывать сторипоинты к часам?

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

или в ЛПР?