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

Backlog Refinement

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

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

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

Зачем нужен рефайнмент?

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

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

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

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

Можно обойтись без Product Backlog Refinement?

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

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

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

Когда проводить Product Backlog Refinement

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

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

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

Кто проводит бэклог рефайнмент?

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

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

Как провести backlog refinement

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

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

Какие инструменты использовать для backlog refinement?

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

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

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

Как сильно нужно «причесывать» бэклог?

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

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

Как оценить результаты product backlog refinement

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

Кейс проведения refinement

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

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