Зачем нужен Product Backlog Refinement и как его проводить

Чтобы потратить меньше времени на планирование спринта. Прийти к нему с уже проработанными, детализированными и всем понятными задачами (User Story).

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

Скрам–команда (обязательно вместе с Владельцем Продукта) и заинтересованными лицами

Backlog Refinement (рефайнмент) — это встречи, на которых команда пересматривает список задач — бэклог продукта. Решает, что улучшить,»почистить», оценивает приоритетность задач и все максимально детализирует.

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

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

Чтобы потратить меньше времени на планирование спринта. Прийти к нему с уже проработанными, детализированными и всем понятными задачами (User Story). С пониманием, сколько надо потратить на них времени, как оценить готовность и результат. Сделать так, чтобы все элементы бэклога соответствовали вашим Definition of Ready — Критериям готовности Задач в Scrum.

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

Если вы все еще не решили, что backlog refinement — это важная штука, на которую стоит потратить время, вот более детальные выгоды:

• Не попадете в ситуацию, когда приоритетные задачи отодвигаются из–за менее важных.
• Каждый раз будете иметь перед глазами четкие и понятные требования к продукту, хорошо подготовленные пользовательские истории который делает команда.
• Сможете вовремя распознать и увидеть риски. Ситуации бывают разные, в большом списке задач легко что–то упустить, не рассчитать силы и время, и совершить ошибку.
• Синхронизировать команду, чтобы все видели цель и шли к ней. Вдруг кто–то незаметно ушел не в ту сторону.
• Product owner, заказчик и другие ответственные и заинтересованные получают еще одну возможность, чтобы что–то уточнить, изменить приоритеты на выполнение задач.

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

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

Как результат, обсуждение затягивается на несколько часов, команда погружается в долгие дискуссии и дебаты. Хороший product owner должен делать все возможное, чтоб подобного избежать.

За два–три дня до следующего планирования спринта, чтобы уточнить, что делать. Или в оговоренный день, один раз в неделю. Лучше посередине спринта.

Это должны быть короткие встречи — не больше 10% рабочего времени. Если спринт рассчитан на 2 недели, то backlog refinement займет 2-3 часа. Если у вас недельные спринты — то час–два. Справитесь быстрее — отлично!

В компаниях, которые работают по скрам, команды посвящают обсуждению одной пользовательской истории из бэклога 15-20 минут ежедневно. Весь день до следующей встреча они проводят что–то вроде самостоятельной разведки, копаются в истории, смотрят на нее с разных сторон. Так они приходят к планированию более подготовленными. Этот подход позволяет на планировании спринта сразу переходить к «распилу» пользовательской истории на задачи и подзадачи и брать их в работу. На это уходит 10 минут. Это экономит в совокупности два (!) часа на планирование (при двухнедельных спринтах).

На встрече должны быть:

• Product owner (владелец продукта). Он инициирует встречу и готовит план того, что нужно оценить, пересмотреть. Если нужно дорабатывает пользовательские истории, расставляет приоритеты.
• Скрам–мастер — следит, чтобы все высказались по делу, не обсуждали ерунду и не спорили по пустякам.
• Заказчик/ответственные лица могут предложить свои идеи для продукта, рассказать что и почему они хотят, указать на важные задачи.
• Члены команды — делятся своими сомнениями, вопросами и предлагают решения.

Для начала еще раз обозначим,что цель рефайнмента — обсудить текущий бэклог продукта, понять, что в нем исправить/поправить и определить, что конкретно делаем.

• Первым делом стоит обсудить со всеми участниками дорожную карту развития продукта. Вдруг что–то изменилось? Что планируется реализовать в ближайшие спринты.
• Если нужно для продукта, напишите новые пользовательские истории, уточните старые, удалите те, что стали неактуальными.
• Проверьте, может, самое время декомпозировать (разложить на составные части — подзадачи) важные задачи. Это даст понимание, каких данных, ресурсов вам не хватает. Декомпозировать лучше так, чтобы выполнение укладывалось в спринт.
• На следующем шаге предложите команде оценить риски и препятствия, которые могут возникнуть при выполнении задач из бэклога.
• Настало время обсудить со всеми участниками встречи элементы бэклога: что это за задача и зачем она? Важно, чтобы все одинаково все понимали. Проверяйте каждую задачу, соответствует ли она вашим Defenition of Ready.
• Расставьте приоритеты для каждого нового элемента бэклога. Уточните их для старых задач. Здесь отлично подойдет модель Weighted Short Job First. Ее использование позволяет получить максимальную экономическую выгоду.
• Вместе с заказчиками или ответственными лицами сформулируйте четкие и всем понятные критерии приемки по каждому элементу.
• Отразите на дорожной карте то, как будет дальше развиваться продукт. Убедитесь, что заказчики и ответственные лица с этим согласны.

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

Для упорядочивания компании используют параметры: Value и Efforts. Их сравнение помогает расставить приоритеты и выбрать самые важные задачи.

• Value показывает, какую ценность приносит выполнение задачи для заказчика и компании в целом. Насколько она важна для реализации всего продукта.
• Efforts считает ресурсы, которые нужны для выполнения задачи.

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

Когда же заполнять стальные 30%? Ответ прост: прямо во время спринта. Команды устранят их, выполняя свою работу. Но для этого критически важно, чтобы product owner был доступен для команды на протяжении всего спринта.

• Вы точно справились, если от вида бэклога команда и владелец продукта не впадают в панику или уныние. Все упорядочено и всем понятно.
• Когда в вверху бэклога стоят задачи, которых хватит на два–три спринта.
• User Story (пользовательские сценарии) согласованы и понятны всем участникам команды разработки.
• Все пользовательские и технические истории в бэклоге оценены командой. Согласованы сроки реализации, учтены риски и высказаны все сомнения.
• User stories так декомпозированы, что можно реализовать сразу несколько из них в ходе одного спринта.

Компания разрабатывает систему для крупного образовательного продукта. В работе над ним стали регулярно проводить baclog rafinement. Какие выводы сделали:

• Это встречи позволили прояснить, что команда не знает по задачам, каких данных ей не хватает.
• На одной из встреч выяснилось, что для реализации элементов бэклога команде не хватает определенных компетенций. Было принято решение — привлечь разработчика–консультанта с опытом и кейсами по этим вопросам.
• Рефайнмент бэклога давал возможность обсудить разные варианты реализации пользовательских и технических сценариев. Команда искала и находила альтернативы. В итоге у всех участников был фокус на проблеме. И к моменту планирования спринта сложные сценарии уже были «разложены по полочкам».
• Рафайнмент позволил находить простые и понятные решения проблем. Например, в одну из встреч было решено отказаться от самостоятельной разработки сложного участка и купить библиотеку готовых решений.