Планирование Итерации (Iteration Planning) в SAFe

Для кого эта статья

Материал предназначен для менеджеров продуктов и руководителей направлений, Владельцев Продукта, Скрам Мастеров / Коучей Команды, RTE, руководителей разработки и тестирования, а также для заинтересованных лиц, которые участвуют в планировании и организации доставки в рамках SAFe.

Кратко о статье

В статье рассматривается, что такое Планирование Итерации в SAFe, зачем оно нужно бизнесу и команде, каковы его исходные данные и результаты, как проходит встреча, кто в ней участвует, каким образом команда подтверждает обязательства по целям итерации, оценивает Истории и прогнозирует свою ёмкость. В завершение приведены практические рекомендации, типовые сложности и ответы на часто задаваемые вопросы.

Что такое Планирование Итерации в SAFe?

Планирование Итерации – это мероприятие SAFe Scrum, в ходе которого команда определяет, какой объём работы из Беклога Команды она может взять на предстоящую итерацию. Результатом мероприятия становятся согласованные Цели Итерации, за выполнение которых команда берёт на себя обязательства, набор отобранных Историй, зафиксированных в Беклоге Итерации, и общее понимание того, как команда будет достигать запланированного результата.

Планирование Итерации – это не просто распределение задач на ближайшие две недели. Это механизм синхронизации приоритетов, доступной ёмкости, зависимостей, рисков и фокусировка всей команды на получение общего ожидаемого результата.

Назначение и ценность для бизнеса

Планирование Итерации – первое мероприятие итерации. Его задача – перевести Цели Интервала Планирования и текущие продуктовые приоритеты в реалистичный, выполнимый и прозрачный план на краткосрочный период работы команды.

Что даёт проведение мероприятия «Планирование Итерации»?

Планирование итерации помогает:

• согласовать ожидания команды, Владельца Продукта и заинтересованных лиц;
• определить реалистичный объём работы на ближайший период – одну итерацию;
• сфокусировать команду на достижении Целей Итерации и Интервала Планирования (PI);
• заранее выявить зависимости, ограничения и риски;
• повысить прозрачность выполнения работ;
• улучшить качество краткосрочного прогноза;
• снизить риск перегрузки команды;
• сократить объём переноса незавершённой работы между итерациями.

Ценность для бизнеса

С точки зрения бизнеса качественное Планирование Итерации повышает предсказуемость доставки и снижает управленческую неопределённость. Руководители и заинтересованные лица получают не просто перечень задач, а понятный ответ на три вопроса:

• выполнение чего команда реально завершит в ближайшей итерации?
• какой результат это даст?
• какие ограничения и зависимости могут повлиять на выполнение плана?

«На практике ценность Планирования Итерации для бизнеса заключается не в проведении самой встречи, а в качестве договорённостей, которые формируются по её итогам. Если команда выходит со встречи с ясными целями по созданию своей части ценности, реалистичным объёмом работ и понятными зависимостями, управлять развитием продуктов и бизнеса становится значительно проще.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Цель мероприятия

Цель Планирования Итерации – определить, организовать и согласовать работы на предстоящую итерацию, а также принять на себя со стороны всех участников команды обязательства по достижению целей итерации.

Иными словами, по итогам мероприятия команда должна ответить на следующие вопросы:

• что именно берётся в работу?
• почему именно этот объём является приоритетным?
• достаточно ли у команды и у каждого её участника ёмкости и возможностей?
• какие риски и зависимости необходимо учесть?
• какая созданная ценность будет говорить о достижении результата итерации?

Контекст проведения Планирования Итерации

Встреча по планированию итерации обычно занимает около 90 минут для двухнедельной итерации. Во многих командах достаточно 60 минут, однако новым командам или командам с высокой степенью неопределённости может потребоваться больше времени, например, около 2х часов при условии заранее предварительно обсуждённых и примерно оценённых Историй.

Предварительный беклог команды частично формируется заранее, в том числе на Планировании Интервала (PI Планировании). Дополнительно на Планирование Итерации влияют:

• результаты предыдущих итераций;
• обратная связь по итогам Демонстраций Системы (System Demo);
• изменения приоритетов;
• новые риски и зависимости;
• локальный контекст команды, включая дефекты, сопровождение и технический долг.

Исходные данные и результаты Планирования Итерации

Исходные данные

К входным данным Планирования Итерации относятся:

• Уточнённый Беклог Команды, включая:
  • Истории, предварительно распределённые по итерациям на мероприятии «PI Планирование»,
  • новые Истории,
  • дефекты,
  • задачи по рефакторингу,
  • задачи по сопровождению,
  • элементы технического долга;
• Цели на весь Интервал Планирования команды, которые были сформулированы во время мероприятия «PI Планирование»;
• Обратная связь по итогам Демонстраций Системы;
• Результаты предыдущих итераций, включая непринятые Истории, не соответствующие Определению Выполненности / Завершённости (Definition of Done, DoD).

Результаты

В результате Планирования Итерации команда получает:

• Финализированные формулировки Историй, запланированных на предстоящую итерацию, включая Энейблеры;
• Финализированные критерии приёмки и оценки для всех отобранных Пользовательских Историй и Историй-Энейблеров;
• Договорённости команды о предварительном распределении и координации работы внутри команды для успешной реализации всех Историй;
• Полностью сформированный и зафиксированный Беклог Итерации (на 2 недели работы, если принятая длительность итерации составляет 2 недели);
• Согласованные Цели Итерации, за выполнение которых команда берёт на себя обязательства;
• Понимание зависимостей с другими командам;
• Договорённости о дальнейшей координации по этим зависимостям.

«Хороший результат Планирования Итерации – это не длинный список задач, а короткий и понятный каждому в команде единый ответ на вопрос: «Какой результат вся команда совместно обязуется показать к концу итерации?». Если такого ответа нет, планирование, скорее всего, проведено формально или команда по какой-то причине не является одной командой.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Подготовка к Планированию Итерации

Качество Планирования Итерации напрямую зависит от подготовки. Если Беклог Команды не уточнён заранее, критерии приёмки Историй размыты, а доступность участников не подтверждена, встреча быстро превращается в затянутое уточнение вместо принятия решений.

Перед встречей рекомендуется:

• завершить работу по предыдущей итерации: закрыть принятые Истории, а незавершённые вернуть в беклог и переприоритизировать;
• провести уточнение/улучшение беклога и убедиться, что Истории достаточно проработаны;
• проверить, что в Беклоге Команды достаточно элементов для выбора на итерацию;
• уточнить и зафиксировать отпуска, праздничные дни и иную недоступность участников на время будущей итерации;
• свериться с Целями на Интервал Планирования и ближайшими Фичами (обычно визуализируются на Доске планирования Поезда (AgileRelease Train, ART);
• Владельцу Продукта убедиться, что он понимает основные продуктовые уточнения, корректировки и приоритеты на уровне Поезда, касающиеся своей команды;
• при необходимости Владелец Продукта может подготовить предварительный вариант целей итерации.

Практический чек-лист подготовки к мероприятию

Перед встречей полезно проверить:

• назначено ли время и определён ли формат встречи?
• доступны ли все ключевые участники?
• обновлён ли и доступен ли всем участникам инструмент визуализации/управления разработкой?
• понятны ли Владельцу Продукта текущие приоритеты?
• достаточно ли проработаны критерии приёмки Историй, которые будут выносится на планирование?
• нет ли критичных зависимостей, которые следует заранее обсудить?

«Если команда сильно погружается в долгое обсуждение или много спорит о сути Историй на Планировании Итерации, проблема чаще всего не в этой встрече, а в недостаточной предварительной проработке беклога. Чем лучше подготовлен беклог, тем короче и качественнее проходит само планирование. Не забывайте прорабатывать все будущие Истории на мероприятии Уточнения/Улучшения Беклога.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Как проходит Планирование Итерации?

Обычно встречу открывает Владелец Продукта: он представляет наиболее приоритетные Истории из Беклога Команды и, при необходимости, предварительные цели итерации. Далее команда совместно обсуждает, какой объём работы реально может быть выполнен в ближайшем цикле.

В ходе Планирования Итерации команда:

• определяет доступную ёмкость;
• обсуждает объём работы, сложность, неопределённость и технические риски;
• уточняет критерии приёмки;
• при необходимости декомпозирует Истории на задачи;
• оценивает трудоёмкость каждого элемента с использованием относительных оценок (сторипоинтов);
• выбирает объём работ в пределах доступной ёмкости;
• обсуждает зависимости и нефункциональные требования;
• формулирует цели итерации;
• подтверждает обязательства по целям.

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

После завершения планирования команда фиксирует Беклог Итерации в рабочем инструменте и делает его видимым для всех участников и заинтересованных лиц.

Программа встречи: рекомендуемая последовательность

Ниже приведён типовой порядок проведения Планирования Итерации.

«Встреча может начинаться с вступительного слова Владельца Продукта, с описанием основных приоритетов на Итерацию, затем может следовать вступительное слово Скрам Мастера / Коуча Команды с организационными вводными, например, по процессу планирования или коммуникаций.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

1. Определение ёмкости команды

Участники подтверждают и фиксируют свою доступность на предстоящую итерацию. Команда учитывает отпуска, праздничные дни, частичную доступность и другие ограничения.

«В случае отсутствия исторических данных команда определяет свою ёмкость по эмпирическому правилу, рекомендуемому SAFe. Однако, если команда имеет опыт совместной работы и исторические данные, совместно со Скрам Мастером / Коучем Команды они могут вывести и утвердить своё правило определения предварительной ёмкости на итерацию.

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

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

2. Анализ и оценка Историй

Команда совместно с Владельцем Продукта рассматривает приоритетные Истории, уточняет критерии приёмки, обсуждает технические аспекты и оценивает объём работ.

«Такое обсуждение часто включает предварительное обсуждение, кто в команде будет вовлечен в выполнение каждой из Историй. Это нужно для балансировки загрузки внутри команды и для валидации корректности определения ёмкости всей команды на итерацию. Некоторые команды явно выделяют по каждой Истории отдельные Задачи.

В последнем случае важно, чтобы эти Задачи не становились жёсткой ответственностью конкретного человека – многое может произойти даже за короткое время итерации, но нам важно, чтобы команда в целом достигала Цели Итерации – выполнение «только своих задач» отдельным участником вряд ли создаст существенную ценность.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

3. Выбор объёма работы на итерацию

На основе приоритетов и доступной ёмкости команда определяет, какой набор Историй реалистично взять в работу.

«На практике пункты 2 и 3 часто выполняются в цикле, поскольку чем ближе мы подходим к заполнению ёмкости или выделенной аллокации, тем больше возникает вопросов с неравномерной загрузкой и выполнимостью. Такие вопросы могут потребовать локального пересмотра отдельных Историй, что осуществляется немедленно, чтобы итоговый Беклог Итерации был максимально реалистичен с точки зрения всех участников команды.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

4. Формулирование Целей Итерации

Команда переводит список выбранных Историй в минимальное количество (обычно 1-3) чётко сформулированных целей, отражающих ожидаемый результат итерации.

«Крайне важно, чтобы цели на понятном для всех заинтересованных лиц языке на высоком уровне описывали те элементы ценности, которые команда создаст за итерацию и не включали в себя обязательства, находящиеся вне зоны контроля этой команды или, тем более, являющиеся бизнес-гипотезами. Именно поэтому Целям Итерации посвящена отдельная статья, с которой я рекомендую ознакомиться.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

5. Подтверждение обязательств

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

«Крайне важно, чтобы все участники команды приняли на себя именно обязательство своей команды, а не только «свои задачи» внутри этих обязательств. Этому способствует корректная постановка процесса относительной оценки, совместное обсуждение работы и рисков, совместное формулирование финальной версии целей итерации и, как подтверждение всего – голосование с целью выяснить уверенность каждого члена команды в выполнимости командных целей.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Ориентир по времени

Для двухнедельной итерации можно использовать следующий ориентир:

• 5 минут – вводные, открытие мероприятия;
• 5 минут – подтверждение доступности и расчёт ёмкости;
• 20–30 минут – анализ и оценка Историй;
• 5–10 минут – формулирование Целей Итерации;
• оставшееся время – согласование итогового состава работ и подтверждение обязательств.

Рисунок 1. Пример программы Планирования Итерации

Обязательства по Целям Итерации

Цели Итерации обеспечивают ясность, фокус и прозрачность. Они нужны не только команде, но и бизнесу: именно на основании целей можно понять, какой результат должен быть достигнут к концу итерации.

Обязательства по Целям Итерации (Рисунок 2):

• Выравнивает понимание внутри команды и со-направляет участников команды вокруг общего набора Целей на Итерацию;
• Помогает команде сохранять фокус на Целях Интервала Планирования;
• Делает план понятным для заинтересованных лиц;
• Упрощает принятие решений при изменениях в ходе итерации.

Рисунок 2. Рекомендации по командным обязательствам

Как подтверждаются обязательства (голосование уверенности команды)?

Команда может использовать короткое голосование по уровню уверенности, например:

• «от одного до пяти» пальцев («fist of five»);
• «Римское» голосование (большой палец вверх, вбок или вниз);
• любой другой заранее согласованный способ.

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

«Низкая оценка уверенности – это полезная управленческая информация. Ошибкой будет пытаться быстро «продавить» согласие. Рациональнее понять, какие именно риски видит участник, и решить, нужно ли корректировать объём, формулировки целей или условия выполнения.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Участники Планирования Итерации

В Планировании Итерации участвуют:

• Владелец Продукта,
• Скрам Мастер/Коуч Команды,
• обязательно — все остальные участники Agile-команды,
• при необходимости – профильные эксперты,
• представители других Agile-команд, поездов или заинтересованные лица, если требуется согласование зависимостей.

«Крайне важно с максимальной осторожностью относиться к приглашению внешних участников, не являющихся членами команды, на Планирование Итерации, поскольку эти участники мероприятия не будут брать на себя ответственность (это не их команда), но могут «давить» или оказывать любое другое негативное влияние на процесс.

Наилучшим вариантом будет все необходимые вопросы обсуждать с внешними по отношению к команде экспертами или лидерами на мероприятии «Уточнение/Улучшение Беклога», и, уже имея эти договоренности, планировать работу только в кругу участников команды. К сожалению, это не всегда возможно, поскольку динамика изменений может быть достаточно высокой.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Роли в рамках встречи обычно распределяются следующим образом:

• Владелец Продукта отвечает за приоритеты и бизнес-контекст;
• команда оценивает объём, способ выполнения и реалистичность плана;
• Скрам Мастер / Коуч Команды помогает удерживать структуру встречи и качество взаимодействия, для некоторых команд, особенно вновь организованных, он выступает более активным ведущим мероприятия, при этом, полностью оставляя бизнес- и продуктовый контекст Владельцу Продукта.

Ведение Планирования Итерации

Ведение мероприятия (фасилитацию) обычно обеспечивает Скрам Мастер/Коуч Команды. В отдельных случаях роль активного ведущего может выполнять Владелец Продукта. Задача фасилитатора – не просто «провести встречу по регламенту», а помочь команде прийти к ясному, реалистичному и разделяемому всеми участниками плану.

Практики эффективной фасилитации

Полезные практики фасилитации:

• придерживаться принятой и понятной структуры встречи;
• удерживать фокус на целях итерации, а не на второстепенных деталях;
• вовлекать в обсуждение всех участников команды;
• следить за тем, чтобы обсуждение не уходило в глубокую техническую проработку, если это не влияет на решение о включении Истории в план;
• фиксировать договорённости сразу в рабочем инструменте;
• обсуждать низкий уровень уверенности в плане без давления;
• при необходимости многократно использовать короткое голосование по уровню уверенности команды в отдельных вопросах;
• завершать встречу только после явного подтверждения обязательств по целям.

Если планирование проходит в удалённом формате

Если встреча проходит дистанционно, важно:

• обеспечить всем участникам доступ к единому рабочему пространству;
• демонстрировать экран при формулировании целей и выборе историй;
• постоянно поддерживать актуальность инструментария управления работами (например, доску команды со списком Историй) в стиле «решили – сразу зафиксировали»;
• делать короткие паузы, если обсуждение затягивается;
• отдельно вовлекать в обсуждение менее активных участников;
• использовать удобный для всех дистанционный способ подтверждения обязательств.

«В удалённом формате не всем участникам легко/комфортно включаться в обсуждение самостоятельно. Поэтому фасилитатору важно не ждать инициативы, а целенаправленно вовлекать участников: спрашивать мнение, проверять согласие, уточнять риски. Иначе можно получить формальное согласие без реального выравнивания участников.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Оценка Историй и прогнозирование ёмкости команды

Относительная оценка Историй для планирования

Agile-команды используют сторипоинты для относительной оценки Историй. Размер каждого элемента сравнивается с другими Историями. Например, История на 8 сторипоинтов обычно требует примерно в четыре раза больше усилий, чем История на 2 сторипоинта.

Относительная оценка помогает:

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

Прогнозирование ёмкости команды

Команда прогнозирует ёмкость итерации, используя историческую пропускную способность (скорость) как отправную точку. Чем дольше команда работает вместе, тем стабильнее становится её фактическая пропускная способность от итерации к итерации.

Расчёт ёмкости команды помогает:

• точнее планировать объём;
• избегать системной перегрузки;
• ограничивать объём незавершённой работы;
• повышать устойчивость доставки.

Стартовая ёмкость для новых команд

Если команда новая и историческая скорость ещё не сформировалась, можно использовать упрощённый подход:

1. Принять за основу 8 сторипоинтов на каждого разработчика, работающего полный день;
2. Вычесть 1 сторипоинт за каждый день отпуска, праздника или иной недоступности в рамках итерации.

Этот подход не заменяет фактическую статистику и исторические данные, но позволяет получить первоначальную рабочую гипотезу возможной ёмкости команды.

Рисунок 3 показывает пример прогноза ёмкости для новой команды из семи человек .

Рисунок 3. Пример стартовой ёмкости для новой команды

Единая основа оценки в рамках Поезда (ART)

На уровне Поезда (Agile Release Train, ART) команды принимают общую опорную логику (нормализацию) оценки, чтобы повысить сопоставимость и качество прогноза.

Один из рекомендуемых практических подходов:

1. Каждая команда выбирает небольшую Историю, на разработку, тестирование и валидацию которой требуется один день, и принимает её за Историю размером «1 сторипоинт».
2. Все остальные Истории оцениваются относительно этого ориентира.

Это упрощает обсуждение Фич и Эпиков, в реализации которых участвуют несколько команд.

«Важно помнить, что цель сторипоинтов – не «точно посчитать трудозатраты», а помочь команде принимать решения о сложности выполнения работы и повышать предсказуемость. Как только сторипоинты начинают использоваться как инструмент давления или сравнения команд и людей, качество оценки быстро падает.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Действия после мероприятия

После завершения планирования рекомендуется:

• обновить Беклог Итерации и внести все изменения в рабочий инструмент управления работой;
• убедиться, что выбранные Истории, оценки и критерии приёмки отражены корректно;
• в некоторых случаях при необходимости скорректировать ёмкость, если появились новые ограничения, и, если это ставит под угрозу цели итерации, – обсудить всей командой;
• опубликовать Цели Итерации в принятых каналах коммуникации;
• согласовать дальнейшие шаги по зависимостям с другими командами;
• убедиться, что все участники одинаково понимают, с чего начинается работа каждого в итерации.

Типовые сложности и как с ними работать

Ниже приведены наиболее распространённые проблемы, которые возникают на Планировании Итерации, и практические подходы к работе с ними.

1. Команда регулярно планирует больше, чем способна выполнить

Как это проявляется:

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

Возможные причины:

• переоценка собственной ёмкости;
• давление со стороны бизнеса/Владельца Продукта/Архитектора и т.д.;
• недостаточная проработка Историй;
• игнорирование незапланированной работы;
• слабый учёт зависимостей и технических рисков.

Что делать:

• зафиксировать и показать команде фактические данные по переносу и незавершённой работе;
• обсудить причины перегрузки на основе фактов, а не предположений;
• сократить планируемый объём работ на следующую итерацию;
• выделить резерв на непредвиденные работы;
• не включать в обязательство работы с высокой неопределённостью без дополнительного обсуждения;
• пересмотреть способы и качество уточнений беклога командой.

«Если команда постоянно берёт больше, чем успевает выполнить, проблема чаще всего связана не с недостаточной мотивацией, а с некорректной калибровкой планирования. Как правило, помогает не усиление контроля, а опора на фактическую скорость, отказ от чрезмерно оптимистичных допущений и честное признание реальных ограничений.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

2. Один участник постоянно перегружен

Как это проявляется:

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

Возможные причины:

• низкая взаимозаменяемость внутри команды;
• концентрация критически важных компетенций у одного человека;
• слишком крупные или узкоспециализированные Истории;
• распределение работы по принципу «кто лучше знает, тот и делает».

Что делать:

• перераспределять работу внутри команды;
• делить крупные Истории на более мелкие;
• использовать парную или совместную работу;
• развивать T-образные (T-shaped) навыки и смежные компетенции участников;
• заранее проверять и учитывать такие ограничения при планировании итерации;
• не строить план, критически завязанный на одном человеке в принципе.

«Если план итерации зависит от одного незаменимого эксперта, это изначально неустойчивая конструкция. В краткосрочной перспективе команда может «проскочить» и пройти итерацию без серьёзных сбоев, но в среднесрочной – это почти всегда приводит к задержкам, конфликтам, выгоранию и снижению качества.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

3. Участник команды выражает низкую уверенность в плане

Как это проявляется:

Во время голосования уверенности один или несколько участников дают оценку ниже согласованного порога, например ниже 3.

Что это обычно может означать:

• в плане есть скрытые риски;
• не ясны критерии приёмки;
• не учтены зависимости;
• объём работы выглядит завышенным;
• часть команды не разделяет общее понимание плана.

Что делать:

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

4. Истории слишком крупные и не помещаются в итерацию

Как это проявляется:

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

Что делать:

• делить крупные Истории на более мелкие и ценные инкременты;
• проверять, может ли История быть завершена в рамках одной итерации;
• отдельно выносить технические исследования, если в них высока неопределённость;
• до планирования уточнять критерии приёмки и границы объёма.

Дополнительные идеи можно почерпнуть также в статье «История».

«Если История не помещается в итерацию, проблема чаще всего связана не с оценкой, а с размером элемента. В такой ситуации полезнее не спорить о сторипоинтах, а изменить «нарезку» работы. Это может потребовать обучения как команды, так и Владельца Продукта, поскольку источником подобной проблемы бывают и те и другие.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

5. На встрече обсуждается слишком много технических деталей

Как это проявляется:

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

Что делать:

• удерживать фокус на решениях, необходимых именно для планирования;
• выносить глубокие технические обсуждения в отдельные обсуждения;
• фиксировать открытые вопросы и ответственных за их проработку;
• возвращать дискуссию к вопросу: влияет ли это на а) включение Истории в итерацию или б) существенно (больше, чем разница между выбираемыми соседними значениями Модифицированной шкалы Фибоначчи) на её оценку?

6. Зависимости с другими командами выясняются слишком поздно

Как это проявляется:

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

Что делать:

• выявлять зависимости до подтверждения обязательства (например, на проводимых на 2 команды или с представителями других команд сессиях уточнения беклога);
• явно фиксировать внешние точки ожидания во время Планирования Интервала (на Доске Планирования, при необходимости в рисках разных уровней) и на регулярных синхронизациях Поезда;
• договариваться о дополнительной синхронизации сразу после планирования;
• отражать зависимости в рабочем инструменте;
• при высокой неопределённости не включать зависимые элементы в обязательство без оговорок (см. статью «Цели Итерации»).

Проводим Планирование Итерации: расширенные практические рекомендации

Ниже приведён набор некоторых практик, которые повышают качество Планирования Итерации.

1. Поддерживайте Беклог Команды в готовом к планированию состоянии

Планирование должно быть пространством для принятия решений, а не для первичного разбора сырых требований. Если Истории не уточнены, критерии приёмки расплывчаты или, тем более, отсутствуют, а ценность не ясна, команда будет тратить время на устранение базовой неопределённости вместо планирования.

Что помогает:

• регулярное уточнение беклога – хорошей считается ситуация, когда у команды всегда уточнён беклог на 2 итерации вперёд;
• договорённости об Определениях выполненности (DoD) команды достигнуты до начала мероприятия;
• раннее выявление зависимостей (см. выше);
• готовая заранее и понятная команде приоритизация со стороны Владельца Продукта.

2. Планируйте, исходя из реальной доступности, а не из желаемого результата

Одна из самых распространённых ошибок – сначала согласовать объём, нужный бизнесу, а затем пытаться уместить его в фактическую ёмкость команды. Успешное планирование работает наоборот: сначала команда оценивает реальную доступность, затем выбирает объём, который можно выполнить без системной перегрузки.

3. Формулируйте цели итерации через результат, а не через перечень действий

Неудачная формулировка цели итерации – это фактически переписанный список Историй. Качественная, сильная цель отвечает на вопрос, какой результат должен быть достигнут командой к концу итерации.

Например:

• неудачно: «реализовать 5 пользовательских историй по модулю регистрации»;
• лучше: «обеспечить пользователю возможность зарегистрироваться и подтвердить аккаунт без участия поддержки».

«Если цели итерации сформулированы через результат, ими проще управлять. Даже если по ходу итерации меняются детали реализации, команда сохраняет понимание того, что именно обязана доставить.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

4. Оставляйте разумный запас ёмкости

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

5. Явно фиксируйте зависимости и их владельцев

Если зависимость выявлена, но нигде не отражена, велика вероятность, что о ней вспомнят слишком поздно. Поэтому полезно сразу определить:

• в чём состоит зависимость?
• от кого она зависит?
• кто отвечает за коммуникацию?
• к какому сроку требуется внешний ответ или результат?

6. Не подменяйте обязательства по целям обязательством по «каждому элементу списка»

В SAFe команда принимает обязательство по Целям Итерации, а не по механическому исполнению любого списка любой ценой. Это особенно важно, когда в ходе итерации требуется пересмотреть приоритеты, пере-балансировать объём или скорректировать подход.

7. Обновляйте рабочие инструменты во время встречи!

Если договорённости остались только в устном обсуждении, уже на следующий день часть общего понимания будет утрачена. Поэтому сразу на встрече важно оперативно отражать, при этом не тратя на это много времени:

• выбранные Истории;
• оценки;
• Цели Итерации;
• зависимости;
• ответственных по критичным вопросам;
• и т.д. – список может быть дополнен.

8. Используйте статистические данные прошлых итераций, а не субъективные ощущения

Команды значительно точнее планируют, когда опираются на факты, например:

• сколько обычно завершается за итерацию?
• сколько работы переносится?
• где регулярно возникают задержки?
• какие типы задач чаще всего нарушают прогноз?

9. Разделяйте обсуждения «что делаем?» и «насколько глубоко проектируем решение?»

На Планировании Итерации важно договориться, что именно команда берёт в работу и на каких условиях (ограничение сложности) считает этот план реалистичным. Однако не каждая инженерная деталь должна быть проработана в тот же момент. Иначе встреча перегружается и теряет управленческую ценность.

10. Оценивайте не только объём, но и «связность» плана

Иногда по численным показателям план выглядит допустимым, но фактически состоит из слишком большого количества параллельных тем, контекстов и незавершённых направлений. Такой план сложнее выполнить, даже если сумма сторипоинтов выглядит приемлемой.

«Сильные команды планируют не просто «по ёмкости», а по способности доводить работу до результата. Иногда лучше взять меньший объём, но получить завершённый, демонстрируемый инкремент без хвостов и недоделок.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Вывод

Планирование Итерации в SAFe – это не формальная встреча по «заполнению итерации задачами», а ключевой механизм краткосрочного управления доставкой. Именно здесь команда переводит цели Интервала Планирования, продуктовые приоритеты, технические ограничения и реальную доступность в согласованный и выполнимый план.

Качественное Планирование Итерации позволяет:

• повысить предсказуемость доставки;
• сделать обязательства команды реалистичными;
• сократить объём незавершённой работы;
• лучше управлять зависимостями;
• удерживать фокус на результате, а не на механическом «перечне задач».

Если беклог команды подготовлен, цели сформулированы ясно, а команда опирается на фактическую ёмкость и открыто обсуждает риски, Планирование Итерации становится не бюрократической церемонией, а рабочим инструментом управления результатом.

Вопросы и ответы

1) Чем Планирование Итерации в SAFe отличается от Планирования Спринта в Scrum?

По сути, это аналогичное мероприятие. Отличие состоит в том, что в SAFe Планирование Итерации проводится в контексте PI Планирования, Целей на Интервал Планирования, межкомандных зависимостей в Поезде (ART), обратной связи с Демонстраций Системы (System Demo) и более выраженной связи локального плана команды с общим контекстом потока доставки.

2) Сколько времени должно занимать Планирование Итерации?

Обычно для двухнедельной итерации достаточно около 60-90, иногда до 120 минут. Однако фактическая продолжительность зависит от зрелости команды, качества подготовки беклога, количества зависимостей и степени неопределённости в Историях. Новым командам целесообразно закладывать больше времени до стабилизации процесса.

3) Что важнее: цели итерации или список историй?

Для управляемости важны оба элемента, но их функции различаются. Цели итерации отвечают на вопрос, какой результат необходимо получить, а список Историй – какие «кусочки ценности» необходимо для этого создать. Если в ходе итерации что-то меняется, именно цели помогают сохранить управляемость и фокус.

4) Можно ли менять объём работ в течение итерации после принятия обязательств на Планировании Итерации?

Если коротко – то да, можно. Однако, такие изменения должны быть прозрачными, согласованными с Владельцем Продукта, понятными команде и не ставить под угрозу достижение целей итерации. Если цели итерации перестают быть выполнимыми, Владелец Продукта должен отменить оставшуюся часть итерации, после чего командой производится новое Планирование на оставшиеся дни.

5) Нужно ли декомпозировать Истории на задачи во время планирования?

Необязательно. Это целесообразно в случаях, когда команде нужно точнее проверить ёмкость, выявить зависимости, снизить неопределённость и убедиться в наличии необходимых компетенций для выполнения. Зрелые команды нередко планируют на только уровне историй, устно обсуждая дальнейшую координацию по их выполнению.

6) Как учитывать отпуска и неполную доступность?

Сначала рассчитывается «идеальная» ёмкость на основе средней исторической пропускной способности (velocity) или простой формулы (обычно для новой команды), после чего команда корректирует прогноз ёмкости на основе зафиксированной фактической доступности участников на соответствующую итерацию. Удобно иметь единый инструмент учёта доступности и расчёта ёмкости на итерацию.

7) Что делать с Историями, не завершёнными в предыдущей итерации?

Их следует вернуть в беклог команды, переприоритизировать, уточнить причины невыполнения и заново рассмотреть в рамках Уточнения беклога и/или нового Планирования Итерации. Незавершённые Истории также могут быть удалены из беклога. В любом случае, основные решения по дальнейшей «судьбе» таких Историй обычно принимает Владелец Продукта команды. Важно не переносить подобные Истории автоматически из итерации в итерацию без нового осознанного решения.

8) Как понять, что зависимости с другими командами действительно учтены?

Признаки качественной проработки зависимостей:

• зависимость явно зафиксирована;
• понятно, от кого она зависит;
• назначен ответственный за коммуникацию;
• определены ожидаемые сроки;
• дальнейшие шаги отражены в рабочем инструменте.

9) Можно ли брать в итерацию срочные дефекты и незапланированные задачи?

Да, можно. Однако важно не игнорировать сам факт наличия такой работы. Если она возникает регулярно, её необходимо учитывать в ёмкости и оставлять под неё резерв.

10) Что делать, если Владелец Продукта хочет включить в план больше работы, чем команда считает реалистичным?

Наилучший подход – обсуждать не мнения, а фактические данные:

• скорость команды;
• доступность людей;
• статистику переносов;
• риски зависимостей;
• уровень неопределённости.

Задача команды – не просто отказаться, а предложить реалистичный вариант плана. Задача Владельца Продукта – помочь выбрать наиболее ценный, но реалистично доставляемый объём в заданных ограничениях.

Использовались материалы: Scaled Agile, Inc. (вендор), статья «Iteration Planning» (от 14.03.2023). Материал не является официальным переводом.

Перевод, адаптация и дополнительные материалы: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры. В подготовке статьи использованы дополнительные материалы и опыт практического использования SAFe Scrum в организациях.

Почитать дополнительно:

Agile Команда
Команда SAFe Scrum
Команда SAFe Kanban
Владелец Продукта
Скрам Мастер / Коуч Команд
Беклог Команды
Истории
Цели на PI
5 видов ценности целей команд на Интервал Планирования
Цели Итерации: зачем нужны и как использовать в SAFe?
Мероприятия в SAFe (включая мероприятия команды)
Обзор Итерации
Ретроспектива Итерации
PI Планирование
System Demo — демонстрация системы в SAFe

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.