Спасибо, Елена.
Касательно Business Value — на сегодня мы уже используем и ожидаем увидеть фидбек от клиентов в цифрах по окончании текущего PI, но шли к этому тяжело и итеративно:
1ый PI — бизнес смог проставить только Business Priorities.
2ой PI — начали проставлять приблизительное Business Value во время презентации планирования от команд во время PI Planning, но по сути это поле еще никак не работало.
3ий PI — на основе информации с предыдущих PI, бизнес начал проставлять Business Value и направлять команды во время планирования.
4ый PI — Business Value были проанализированы бизнесом и проставлены перед PI Planning, после PI собрали значения по командам и обещют к следующему показать уже реальные цифры результата. Это пока наша последняя итерация.

Спасибо, Андрей. Постараюсь прояснить:
1. Так как доска заполняется в течении двух дней, конечно есть риск потерять какой либо стикер, поэтому в первый день мы просто все заклеивали сверху скотчем :). А на второй день у нас обязательный пункт в расписании: 1 час для всех PO/SM перенести всю информацию в JIRA по своим командам, обычно этого времени достаточно.
2 и 3. Почерк особо разбирать не надо, так как мы в основном указываем номера задач в JIRA и размер задач и приклеиваем на запланированный спринт, всю остальную информацию мы записываем в соответсвующей задаче в JIRA.
4. В конце дня проводится общее ревью перед Confidence Vote, обычно ошибки отлавливаются на этом этапе.
5. Независимо от версии доски, в работе с зависимостями выделяем два этапа:
1) на этапе PI Planning: идентифицируем зависимость, визуализируем, и кратко прописываем как на нас повлияет и план действий, согласуем план на месте с нужными сторонами.
2) на этапе PI (в течении кваратала): PO и SM ответсвенны прослеживать зависимости и насколько план по уменьшению влияния выполняется для каждой соответсвующей задачи.

Спасибо, Игорь. Роль Project Administrator выделена на уровне компании и обычно актуальна для больших эккаунтов (100+чел), где мы сталикиваемся с вопросами организации специфичных для эккаунта внутренних процессов и их поддержки. Основные задачи, помимо подготовки к PI Planning, являются: контроль репортинга и финансовых отчетов, организация процесса ввода новых сотрудников, планирование различных мероприятий на уровне всего эккаунта. С этой роли есть возможность дальше развиваться в Project Management.

Спасибо, Инна. Во время первых PI Planning это действительно очень тяжело и давит, нужно постоянно работать с мотивацией команд. Но в дальнейшем, когда команды понимают как работает планирование и видят пользу на протяжении следующего квартала, то уже сами более мотивированы ориентироваться на хорошую подготовку, чтоб эти два дня прошли быстро и легко.

Спасибо, Андрей! Совершенно верно, постепенно и мы уже пришли к тому что команды начинают ревью требований с PO за две недели. Касательно приоритизации беклога по WSJF — мы не применяем еще. Было бы интересно увидеть на реальных примерах как оно работает, если есть возможность поделиться живыми примерами — была бы благодарна.

Приму к сведению :) Спасибо Сергей.

Спасибо, Вадим!

Спасибо Сергей и Вадим, за комментарии. Во многом согласна с ответами Вадима, добавлю только по нашей специфике:
1. Если мы проводим ретроспективу по достижению целей с предыдущего PI, то основной фокус направлен на улучшение процессов в течении следующего PI (квартала), которые бы позволили нам гарантировать своевременную поставку нового функционала. Также при необходимости мы расширяем список рисков и зависимостей, которые в дальнейшем адресуются уже тоже во время PI. Поэтому проведение такой ретроспективы в конце мероприятия выглядит достаточно логично для нас.
2. В основном незавершенная работа в нашем случае переносится на начало следующего Program Increment, но также возможны варианты новых приоритетов от бизнеса и перенос незавершенных задач на последующие PI Planning.
3. Совершенно верно, это невозможно описывать требования во время PI Planning, и это НЕ является его целью, основная цель при большом масштабе — выявить зависимости, риски и запланировать порядок работ соответственно. И конечно, бизнес требования должны быть проработаны заранее PO — именно это я имела в виду под подготовкой к PI Planning в статье.
4. Для естимейтов на PI Planning мы используем T-shirt sizing (S, M, L). Этот вариант оценки начинает работать эффективно на второй-третий PI Planning, когда у команд уже есть опыт и есть на что опереться в оценках. При ряде факторов: 1) проработанные заранее требования, 2) слаженная Scrum команда, 3) управляемые зависимости — эстимейты достаточно точны и команды доставляют 100% запланированного объема работ.
5. PI Planning практика из SAFe позволила нам адресовать большое количество проблем, с которыми мы сталкивались ранее и не могли качественно и долгосрочно их решить, мы пробовали Scrum of Scrums с различными участниками, проcто регулярные поездки при старте новых больших фич, но именно регулярный PI Planning позволил качественно улучшить процесс непрерывной поставки нового функционала без провисаний по времени и загрузки для 9 команд работающих над одним продуктом. Поэтому для Enterprise стремящихся к Agile разработке, я лично считаю, что PI Planning является эффективным инструментом планирования.

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

Спасибо, Николай, за рекоммендации. Согласна, что при наличии готовых требований Program Increment действительно может проходить быстрее и эффективнее. Мы также пробовали стабилизационные спринты раз в два квартала, этот подход позволяет уделить время техническому долгу и помочь с проработкой требований на следующий Program Increment.