⚡ Kotobotov ⚡

Направление (задачи) разработки меняют основываясь на результаты спринта, поэтому до окончания спринта, сам спринт не меняют. Это фиксированный по времени этап, грубо говоря мы неделю работаем, в конце недели оцениваем нашу работу (не важно сколько успели или не успели) и пытаемся, на основе того что мы сделали, скорректировать направление разработки.
Спринты также фиксированные по длительности для того, чтоб можно было оценивать продуктивность спринтов друг с другом.
Вы конечно можете конечно делать так, как вам удобнее.
П. С.
В подавляющем большинстве случаях под видом гибкой методологии используют обычный ватерфол, с той лишь разницей, что этапы разработки зачем-то называют спринтами, с подробным планом задач на десяток спринтов вперед.

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

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

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

>переход всей разработки на SCRUM, только после того , как мы сможем на цифрах показать выгоду
ваше мышление еще не готово переходить на гибкие методологии.
Многие вещи в цифрах не считаются.
Вам предлагают посчитать в цифрах следующее: идти в магазин ориентируясь на местности или идти в магазин с закрытыми глазами по карте которую вы нарисовали у себя дома, при этом вы никогда не ходили до этого в магазин и вообще не знаете есть ли он там.
По плану и там и там одинаково эффективно вы должны дойти, а в реальности с закрытыми глазами вас через 15 минут пути машина собьет, или вы просто шею сломаете зайдя не туда.
========
Суть в том чтоб за 2 года запланированной разработки, не прийти в помойную яму вместо магазина.
Попытаться все спланировать и посчитать итог работ - это опять из ватерфола, вы живете в недетерминированном мире в котором вы НЕ можете все вокруг посчитать и проконтролировать, вы либо это принимаете и начинаете по другому мыслить и действовать (на основе обратной связи) , либо дальше занимаетесь очковтирательством.
П. С.
бизнес не любит неопределенности, любят гарантии и точные ответы - поэтому заказчик будет все равно ТРЕБОВАТЬ чтоб ему в очки втирали дичь, по поводу обьемов работ и сроков, это основная проблема внедрения гибких методологий, привычка и не желание людей по другому мыслить.

делить разработчиков - ничем не обоснованная мысль - вы не сможете грамотно сбалансировать нагрузку между ними, всегда будет часть разработчиков простаивать - всегда будут кто-то кто медленнее или быстрее будет делать часть работ, больше делений, больше таких вещей.
опять же уверен, лучше всего баги править тому кто делал этот функционал, ему по крайней мере не надо объяснять что там и как работает.
========
По поводу спринтов и фикса багов.
Баги будут всегда, начните разрабатывать продукт предполагая что во всех узлах и модулях уже есть баги (так оно на самом деле и бывает), это сразу поменяет подход к разработке - перейдя на схемы в которых продукт работает независимо от сбоя и багов в отдельных модулях.
В итоге вы получите всегда рабочий продукт независимо от багов, в котором вы можете в любой момент начать отдельные спринты по повышению качества его работы (снижению уровня багов).
В текущем спринте вы работает только над текущими поставленными задачами - это закон (ничего другого не берете). Срок спринта фиксирован - что успели то успели, все остальное переносится или на другой спринт, или вообще выкидывается.
В этом вся суть, иначе какой вообще смысл в этих спринтах если вы просто там сидите и над какими-то багами из прошлых этапов ковыряетесь.

ТЗ? - нету там никакого ТЗ, при такой методике разработки.
есть виденье, что хотим получить, каждую итерацию (неделю/месяц), думаете какие задачи для достижения виденья будете решать, куда будете двигаться дальше, корректирую на обратную связь с заказчиками.
и не факт что вообще к тому что изначально планировали, придёте, это само виденье куда идёте, может меняться каждую итерацию.