Как оживить ваш PBR. Опыт команды в Открытии


PBR (Product Backlog Refinement) – это процесс уточнения и проработки бэклога, является обязательным процессом Scrum. Многие используют термин Backlog Grooming (груминг) – это тот же самый процесс, то есть PBR и Grooming являются синонимами. Однако термин Grooming считается устаревшим в сообществе, и в Scrum Guide используется термин PBR (Product Backlog Refinement).

Денис Ермаков – Scrum-мастер и Agile–тренер банка Открытие делится опытом применения практики PBR в одной из команд.

Проблематика

Ко мне пришла новая команда, Scrum–мастер которой обратился за помощью в настройке процесса PBR. Ранее у команды встречи PBR проходили нерегулярно, что приводило к недостаточной проработке беклога. Сами PBR встречи проходили в формате “говорящая голова”, где в основном говорил Product Owner. Встречи проходили в онлайне, участники легко отвлекались, переключались на выполнение своих текущих задач, вовлеченность и динамика были низкими. 

Хорошей практикой является регулярное проведение PBR встреч, например один раз в неделю по 60-90 минут, с участием всей Scrum команды. Задача скрам мастера – провести эту встречу с максимальным вовлечением каждого участника. 

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

Как прошел следующий PBR?

PBR Canvas помог структурировать встречу, cфокусировать участников на конкретных вопросах в процессе проработки пользовательских историй. Сперва Владелец продукта озвучил User story, затем совместно думали над вопросами и обсуждали ответы. Далее перешли к подзадачам, затем сформулировали критерии приемки, а после выявили зависимости. Завершили проработку истрии совместной оценкой с использованием техники Planning Poker. 

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

Что получилось в итоге:

Все участники отметили формат PBR Canvas как более эффективный способ проведения встречи.

Лично я для себя вынес следующие инсайты:

  • Правильно сформулированная US избавляет от нудного изложения деталей со стороны аналитика или другого “владельца требований”. Таким образом, можно сразу перейти к секции Вопросы-Ответы
  • Удалось уйти от формата “Говорящей головы”
  • Пик вовлечения и максимум извлечения деталей возникает на этапе Вопросы-Ответы (я давал 5 минут на генерацию вопросов в режиме индивидуальной работы на стикерах) – говорящая голова уже озвучивает то, что считает важным группа, а не лично он.
  • Активность естественным образом перетекает на критерии приемки: после секции Вопрос-Ответ тестировщики и разработчики моментально формулируют критерии. Здесь тоже выяснилось несколько невыясненных серых зон касательно ожидаемого поведения системы и пользователей – возникла пища для размышлений со стороны Владельца Продукта.
  • PBR Canvas занимает чуть больше времени, чем неструктурированное обсуждение. Примерно 45 минут против 30 для истории размера M. Однако, групповая динамика и вовлеченность гораздо выше, что приводит к более качественной проработке истории.

Но самый главный урок в том, что практику PBR Canvas нужно делать в коллаборативном режиме: либо на онлайн-доске в Miro либо на флипчарте в оффлайне. Подмена инструментов (например, обсуждение в режиме аудиозвонка без использования “белой доски”) убивает все преимущества метода. И наоборот – коллаборативная среда провоцирует сотрудничество и вовлечение.

Подробная инструкция по проведению

Первым делом мы заполняем блок с наименованием истории. Здесь важно сформулировать историю в виде User Story или Job Story для того, чтобы всем участникам была понятна суть и бизнес-ценность. Также хорошая практика – указать номер US в вашем трекере.

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

Далее переходим к блоку Вопрос–Ответ

Фасилитатор запускает сессию (5-7 минут) по генерации вопросов. Участникам предлагается индивидуально подумать о реализации данной истории и выписать на стикеры вопросы, которые возникают при таких размышлениях. Один вопрос на один стикер. От каждого участника один или несколько вопросов.

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

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

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

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

Подзадачи

Как только вы прошлись по всем вопросам – переходите к подзадачам. Что именно будет сделано в рамках истории?

Проведите обсуждение голосом  – задайте в группу вопрос “Что должно быть сделано?”. Скрайбируйте ответы, выделяйте цветом то, что должно быть сделано совершенно точно, и то что “возможно” должно быть сделано, или то что требует уточнений.

Как только идеи иссякнут – переходите к секции Критерии приемки.

Критерии приёмки

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

Как только приемочные критерии сформулированы переходите к блоку зависимостей.

Зависимости

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

В секции “Влияет на” укажите какие истории находятся в зависимости от рассматриваемой истории.

Оценка истории

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