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

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

Пошаговый алгоритм создания бэклога продукта для Scrum-команд.

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

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

product-backlog

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

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

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

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

product-roadmap

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

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

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

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

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

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

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

user-story

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

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

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

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

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

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

product-backlog

Кажется, задач в бэклоге всё больше, а выбрать, с чего начать — всё сложнее?

Научим вашу команду формулировать, оценивать и приоритизировать задачи так, чтобы было понятно, за что браться в первую очередь — и зачем.

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотите системно изучить гибкие методологии?

Сертифицированный Владелец продукта в Agile

25 - 27 июня 2025
Узнать больше

Фреймворки масштабирования Agile

23 - 25 июля 2025
Узнать больше

Профессиональный сертификационный тренинг по Agile и Scrum

29 - 31 июля 2025
Узнать больше

Полный календарь тренингов

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

Еще публикации по Agile в Управление продуктами

Разработка и запуск корпоративного портала «с нуля» за 3 недели
Кейс Телекоммуникации

Разработка и запуск корпоративного портала «с нуля» за 3 недели

Наш клиент, одна из крупнейших телекоммуникационных компаний России, поставила перед нами задачу быстрого запуска «с нуля» нового программного продукта — внутреннего портала для десятков тысяч сотрудников компании, распределенных по всей стране.

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum
Публикация Управление продуктами

Почему мы мыслим короткими циклами, но не хотим переходить на Scrum

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

PI планирование
Публикация Управление продуктами

PI планирование

Что такое PI планирование, или Планирование инкремента продукта, когда используется и как его проводить.

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!