Уточнение бэклога в LeSS — Product Backlog Refinement | OnAgile Consulting

Уточнение бэклога в LeSS — Product Backlog Refinement

В LeSS уточнение бэклога продукта бывает нескольких видов. Многокомандный PBR — это когда все команды собираются вместе, чтобы проработать бэклог. Общий PBR — это обзор бэклога всеми командами или их представителями. Однокомандный PBR — это работа одной команды над отдельной, более сложной задачей.

Уточнение бэклога продукта (Product Backlog Refinement, PBR) - это фундаментальный и непрерывный процесс, который происходит в течение каждого спринта для проработки элементов бэклога, которые будут взяты в следующие спринты.

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

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

В рамках LeSS PBR является конкретным формальным событием (встречей), а не просто фоновой активностью как в обычном Scrum. Важно отметить, что в этом процессе участвует вся команда, а не только владелец продукта или часть команды, например, аналитики. Поэтому такой подход значительно снижает потери, связанные с передачей информации между участниками процесса.

В LeSS существует три типа PBR:

  • Многокомандный PBR
  • Общий PBR
  • Однокомандный PBR

Давайте разберем каждый тип PBR в рамках масштабного Scrum (LeSS) в более подробном виде.

Многокомандный PBR (основной тип)

Можно считать, что это большой мозговой штурм, когда несколько команд собираются вместе для работы над бэклогом продукта. Это как сердце LeSS, наполняющее жизнью спринты и весь процесс работы команд. Цель состоит в том, чтобы способствовать общему пониманию между командами, найти возможности для сотрудничества, согласовать оценки и повысить адаптивность команд.

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

Уникальная стратегия, используемая в многокомандном PBR, - это "уточнение бэклога в смешанных группах”.

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

Общий PBR

Это более упрощенная версия, чем PBR для нескольких команд. Достаточно короткая, высокоуровневая сессия, направленная на развитие базового понимания обо всех предстоящих пунктах среди всех команд.

На общем PBR присутствуют владелец продукта и либо все члены команды, либо несколько представителей от каждой команды. Цель состоит в том, чтобы встреча была эффективной, при этом обеспечивалось представительство всех команд.

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

PBR для одной команды

Это скорее исключение, чем правило в LeSS. Он используется, когда есть масштабная задача, в которую в конечном итоге будут вовлечены многие команды, но на начальном этапе она настолько сложна, что только одна команда берется за ее распутывание. Такая команда обычно называется Ведущая команда.

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

Важно отметить

По сути, каждый тип PBR служит уникальной цели и используется при определенных обстоятельствах. Понимание того, когда и как использовать каждый из них, является ключом к эффективному уточнению бэклога в рамках LeSS. Однако в любом случае, при внедрении LeSS в организации, следует стремиться к как можно более быстрому переходу к многокомандному PBR.

Обсудить масштабирование Scrum и внедрение LeSS для вашей организации, учитывая особенности существующей культуры, можно на корпоративном тренинге LeSS Professional. Мы проведём его специально для вашей команды и поможем разобраться, как выстроить эффективную структуру внутри вашей компании с помощью LeSS.


Мы подготовили серию статей о Large-Scale Scrum и постарались простым языком объяснить, как работает LeSS и как применять его на практике. Статьи можно читать в любом порядке.

Введение в LeSS (Large-Scale Scrum)
Роли и организационная структура в LeSS
Процесс спринта и события в LeSS
Как техническое совершенство в LeSS помогает сохранить качество и гибкость при масштабировании
Принципы и ценности LeSS
Внедрение LeSS в организации
Масштабирование с помощью LeSS Huge


Интересно узнать подробнее?

Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.

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

Почему многокомандный PBR в LeSS дает неожиданное преимущество в скорости разработки?

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

Как ведущая команда в LeSS решает проблему сложных задач, с которыми не справляются другие?

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

Чем уточнение бэклога в LeSS кардинально отличается от обычного Scrum?

В LeSS уточнение бэклога — это формальное событие с четкой структурой, а не фоновая активность как в обычном Scrum. Ключевое отличие в том, что все команды работают вместе над общим бэклогом продукта, что устраняет проблему разрозненного понимания и несогласованности между командами.

Какой неожиданный эффект дает общий PBR для продуктивности команд?

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

Почему успешные компании выбирают многокомандный PBR вместо раздельной работы команд?

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

Как правильное проведение PBR в LeSS предотвращает типичные проблемы масштабирования?

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

Еще публикации по Agile в Гибкие организации

Как в ритейле увеличить выручку, лояльность клиентов и сотрудников. На примере одной из крупнейших сетей АЗС
Кейс Ритейл

Как в ритейле увеличить выручку, лояльность клиентов и сотрудников. На примере одной из крупнейших сетей АЗС

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

Agile в медицине и здравоохранении
Публикация Медицина и здравоохранение

Agile в медицине и здравоохранении

Как Agile подход может помочь здравоохранительным организациям реализовывать и контролировать инициативы по реорганизации процессов.

Как обеспечить развитие организации. Часть 2: Роли в SAFe
Публикация Гибкие организации

Как обеспечить развитие организации. Часть 2: Роли в SAFe

Один из самых популярных фреймворков масштабирования организации — SAFe, или Scaled Agile Framework. Разбираемся, на чем он основан и какие роли есть в SAFe.

Ближайшее обучение по Agile и Scrum

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!