Как создать бэклог продукта в Scrum

Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Прежде чем Scrum-команда приступит к работе в первом спринте, нужно создать бэклог продукта. Бэклог — это полный список всех требований (пользовательских историй) к продукту. Чем качественнее он подготовлен, тем эффективнее будет работа команды в спринте.

Сложность в том, что в самом начале пути Scrum-команде часто не хватает понимания о том, как должен будет выглядеть продукт, и что, собственно, предстоит сделать. С этого и следует начинать подготовку к наполнению бэклога.

Дорожная карта продукта

В случае продуктов, хорошо известных пользователям, и больших компаний наполнять элементами бэклог продукта будет проще, если предварительно сформировать видение и высокоуровневый план развития продукта — дорожную карту (Product Roadmap).

Это необязательный этап: стартапы и инновационные продукты, у которых нет аналога на рынке, на начальном этапе в дорожной карте не нуждаются — в этих случаях стоит начать с пользовательских историй (User Story).

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

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

Работа по Scrum не отрицает постановку долгосрочных целей, однако при наполнении бэклога наиболее подробно следует проработать элементы, которые войдут в первые 1-2 спринта. Элементы для последующих спринтов можно описывать с меньшей степенью детализации — скорее всего, они потребуют доработки с учетом обратной связи.

Не только пользовательские истории

Пользовательские истории (User Story), или описания потребностей клиента, которые он может закрыть с помощью нашего продукта, и пользы, которую получит в результате его использования, — основная часть бэклога. Однако не единственная: при наполнении бэклога важно также уделить внимание техническим работам.

При создании пользовательских историй следует учитывать разные группы пользователей. История обычно строится по принципу «действие и причина»:

как ____, я хочу ____, чтобы ____.

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

Приоритизация

Итак, бэклог наполнен элементами. Теперь пришло время разобраться, сколько усилий потребует выполнение каждого из них (провести оценку трудоемкости) и какие элементы следует взять в работу в первую очередь. Это непростая аналитическая задача, решение которой облегчают инструменты вроде WSJF — об этой методике мы подробно рассказывали в материале «Модель приоритизации бэклога WSJF».

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

Критерии готовности

Прежде чем приступать к работе, важно определить, как команда в процессе работы поймет, что элемент бэклога полностью реализован. Для этого разрабатываются стандартизированные критерии готовности (Definition of Done, DoD), которые гарантируют, что вся команда понимает, какой результат ожидается от выполняемой ими работы.

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

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

Перейти к расписанию

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

Почему опытные Scrum-команды начинают с дорожной карты, а не с бэклога?

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

Какую критическую ошибку допускают новички при создании бэклога продукта?

Главная ошибка - стремление детально проработать весь бэклог на старте проекта. Правильный подход - тщательно описать только элементы для первых 1-2 спринтов, а остальные оставить менее детализированными. Это позволяет быстрее начать работу и корректировать бэклог на основе реальной обратной связи от пользователей.

Как опытные владельцы продукта превращают хаос требований в работающий бэклог?

Они используют двухэтапный подход: сначала собирают все идеи и отзывы от стейкхолдеров и клиентов, формируя общее видение продукта. Затем трансформируют их в конкретные пользовательские истории по формуле 'как ____, я хочу ____, чтобы ____', добавляя технические задачи и критерии готовности (Definition of Done).

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

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

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

Эффективная пользовательская история всегда следует формуле 'действие и причина': как определенный тип пользователя, я хочу конкретное действие, чтобы получить конкретную пользу. Такой формат помогает команде четко понять, для кого и зачем создается функционал, и правильно расставить приоритеты.

Какой секрет приоритизации бэклога используют ведущие Scrum-команды?

Опытные команды применяют метод WSJF (Weighted Shortest Job First), который учитывает не только важность задачи, но и стоимость задержки её выполнения. Это позволяет объективно определить, какие элементы бэклога принесут максимальную ценность в кратчайшие сроки.