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 чтобы убедиться, что все оценивают историю одинаково. Начните обсуждение если есть разброс в оценках. Уточните приемочные критерии и подзадачи на канвасе если потребуется.