Далее, когда подходит время сборки спринта - достаточно сгруппировать список задач MS Project по этой колонке Future sprint, и сразу увидим, сколько часов работ мы предварительно на завесили на какого разработчика:
Возможные перекосы устраняются: работы, превышающие пропускную способность, могут двигаться вперед, либо можно переназначить исполнителя на менее нагруженного, либо можно договориться о сверхурочных (но мне всегда удавалось обходиться без них). На итог, мы должны видеть на ближайший рабочий спринт задачи, распределенные по участникам команды, и в объеме который каждый участник может отгрузить с учетом его доступности. Наша норма доступности на спринт это 75 часов на одного разработчика без учета отпусков и т.д.
Указанным образом, нужно полностью распланировать ближайший будущий спринт, и ориентировочно, на 2/3 заполненности - следующий за ним. Расстановка по спринтам вообще всех задач на более дальний горизонт в моем случае смысла не несет ввиду той самой высокой неопределенности, а также бэклога на уровне 6-7 месяцев (за которые точно появятся новые вводные).
Балансировка спринтов на указанных выше объемах бэклога и команд занимает у меня где-то день работы, со всеми возможными переговорами и утрясаниями разногласий с заказчиками и тимлидами разработки. Но зато спринты получаем исполнимые, логичные, согласованные со всеми причастными. А процент успешного закрытия задач качественно собранного спринта в всегда близок к 100. Но нужно сразу оговориться, что для оперативной сборки планов обязательно нужно иметь:
