Бэклог продукта (product backlog): что это, из чего состоит и как его формировать

Бэклог продукта (product backlog, в текстах встречается и написание «беклог») — это упорядоченный список всего, что нужно сделать для улучшения продукта: новых функций, исправлений, технических работ, исследований. Порядок в списке — главное его свойство: чем выше элемент, тем раньше команда возьмет его в работу и тем подробнее он описан.

Ниже — из чего состоит бэклог, кто за него отвечает, как собрать его на основании пользовательских историй, как расставить приоритеты по MoSCoW, RICE и WSJF и чем бэклог продукта отличается от бэклога спринта.

Три термина, которые путают

Слово «бэклог» в разговоре означает разные списки. Разведем их сразу.

Термин	Что это	Кто отвечает	Горизонт
Бэклог продукта (product backlog)	Упорядоченный список всего, что может понадобиться продукту	Владелец продукта (product owner)	Весь срок жизни продукта
Бэклог спринта (sprint backlog)	Цель спринта, выбранные под нее элементы и план их выполнения	Разработчики	Один спринт
Бэклог релиза (release backlog)	Срез бэклога продукта, намеченный к определенному выпуску	Обычно владелец продукта	Несколько спринтов

Первые два — артефакты Scrum, они описаны в Руководстве по Scrum (Scrum Guide, редакция 2020 года — на сентябрь 2026 года она остается действующей). Бэклога релиза в руководстве нет: это распространенная практика планирования, а не часть фреймворка.

Бэклог используют и вне Scrum — например, в Kanban, где это входная очередь задач перед доской. Дальше речь о бэклоге продукта, а описание ролей опирается на Scrum.

Из чего состоит бэклог продукта

Запись бэклога называют элементом (product backlog item, PBI). Руководство по Scrum не предписывает формат элемента. На практике встречаются четыре типа:

• функции — новое поведение продукта, чаще всего в виде пользовательских историй;
• дефекты — ошибки, найденные пользователями или командой;
• технические работы — обновление зависимостей, рефакторинг, безопасность, производительность;
• исследования (в командах их называют «спайк») — короткая работа ради ответа на вопрос, без которого нельзя оценить другой элемент.

У бэклога есть цель продукта (product goal) — формулировка состояния, к которому продукт должен прийти. Она объясняет, зачем в списке именно эти элементы, и помогает отказывать тому, что к цели не ведет.

Крупные элементы называют эпиками: это работа, которая не помещается в один спринт и позже дробится на истории. Эпик — рабочий термин команд и трекеров задач, в Руководстве по Scrum его тоже нет.

Бэклог — не техническое задание. Он никогда не бывает «готов»: пока продукт живет, список меняется. Элементы добавляют, переписывают, переставляют и удаляют.

Кто отвечает за бэклог

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

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

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

Бэклог на основании пользовательских историй

Чаще всего функции в бэклоге описывают пользовательскими историями (user story). История фиксирует не решение, а потребность: кто пользователь, чего он хочет и зачем. Распространенный шаблон:

Как <роль>, я хочу <действие>, чтобы <ценность>.

Пример для онлайн-школы:

Как студент, я хочу получать напоминание за час до занятия,
чтобы не пропускать вебинары.

К истории добавляют критерии приемки — условия, по которым команда и владелец продукта поймут, что работа сделана. Их удобно писать сценариями в формате «Дано — Когда — Тогда». Этот формат пришел из BDD (behavior-driven development, разработка через поведение):

Дано: студент записан на занятие в 19:00 и разрешил уведомления
Когда: наступает 18:00
Тогда: студент получает уведомление со ссылкой на вебинар

Такой сценарий одновременно уточняет требование и служит основой для теста. Так бэклог, собранный из историй, связывается с BDD-подходом: история отвечает на вопрос «что и зачем», сценарии — на вопрос «как проверить».

Встречается и сокращение BDT (behavior-driven testing, тестирование на основе поведения). Так называют проверку продукта по этим же сценариям: тесты пишут на основании пользовательских историй и их критериев приемки.

История — популярный, но не единственный формат. Дефект или техническую работу не обязательно втискивать в шаблон «Как пользователь, я хочу»: достаточно ясного описания и критериев приемки.

Какой должна быть история в верхней части списка

Для проверки истории используют мнемонику INVEST (ее предложил Билл Уэйк в 2003 году):

• Independent — независимая от других историй, насколько это возможно;
• Negotiable — обсуждаемая: детали можно менять до начала работы;
• Valuable — ценная для пользователя или бизнеса;
• Estimable — поддающаяся оценке;
• Small — достаточно маленькая, чтобы уместиться в спринт;
• Testable — проверяемая по критериям приемки.

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

Как сформировать бэклог: шаги

1. Сформулировать цель продукта. Без нее нечем обосновать порядок элементов.
2. Собрать входящие: запросы пользователей, данные аналитики, обращения в поддержку, идеи команды, обязательные требования (например, законодательные).
3. Записать каждое предложение отдельным элементом: функции — историями, остальное — коротким описанием проблемы.
4. Сгруппировать крупное в эпики, а эпики, которые скоро пойдут в работу, разбить на истории.
5. Вместе с разработчиками оценить размер элементов из верхней части списка.
6. Упорядочить список (методы — в следующем разделе).
7. Добавить критерии приемки элементам, которые могут попасть в ближайшие один-два спринта.

Результат — не документ, а рабочий список в трекере задач, электронной таблице или на доске. Инструмент вторичен. Важнее, чтобы версия была одна и ее видели все участники.

Приоритизация: MoSCoW, RICE, WSJF

Руководство по Scrum требует, чтобы бэклог был упорядочен, но способ не задает. Три распространенных метода отвечают на разные вопросы.

Метод	Что дает	Что нужно на входе	Когда подходит
MoSCoW	Четыре группы: Must, Should, Could, Won’t (обязательно; желательно; можно; не в этот раз)	Договоренность с заказчиком о границах выпуска	Фиксированный срок, нужно определить объем
RICE	Число: Reach x Impact x Confidence / Effort	Данные об охвате и оценка трудозатрат	Много идей, есть продуктовая аналитика
WSJF	Число: стоимость задержки / размер работы	Относительные оценки ценности, срочности, риска и размера	Важна цена промедления

MoSCoW не выстраивает элементы по порядку внутри группы. Типичная ошибка — записать в Must почти все. Must — это то, без чего выпуск теряет смысл.

RICE предложила команда Intercom. Reach — сколько пользователей затронет изменение за период, Impact — сила влияния на одного пользователя (в исходной шкале от 0,25 до 3), Confidence — уверенность в оценках (в исходной шкале 100, 80 или 50%), Effort — трудозатраты в человеко-месяцах.

WSJF (weighted shortest job first) — метод из работ Дональда Рейнертсена, широко известный по фреймворку SAFe. В варианте SAFe стоимость задержки — это сумма трех относительных оценок: ценности для бизнеса, срочности и снижения риска (или открытия новых возможностей).

Один список — два порядка

Посчитаем RICE и WSJF для четырех элементов. Оценки условные, период для Reach — квартал.

Элемент	Reach	Impact	Confidence	Effort	RICE
Оплата через СБП	4000	2	80%	4	1600
Темная тема	6000	0,5	100%	2	1500
Рекомендации курсов	3000	3	50%	6	750
Вход по коду из SMS	800	1	80%	1	640

Проверка первой строки: 4000 x 2 x 0,8 / 4 = 1600.

Теперь WSJF для тех же элементов. Ценность, срочность, риск и размер — относительные оценки по шкале 1, 2, 3, 5, 8, 13.

Элемент	Ценность	Срочность	Риск	Стоимость задержки	Размер	WSJF
Вход по коду из SMS	5	8	8	21	3	7,0
Оплата через СБП	8	5	3	16	5	3,2
Темная тема	3	1	1	5	2	2,5
Рекомендации курсов	13	2	5	20	13	1,5

По RICE вход по SMS — последний: он затрагивает мало пользователей. По WSJF он первый: работа маленькая, а откладывать ее дорого (в примере — из-за жалоб на потерю доступа к аккаунту).

Ни один метод не «правильнее» другого. Формула дает аргумент для обсуждения, а решение о порядке принимает владелец продукта. Он учитывает то, чего в формуле нет: зависимости между элементами, обязательства перед заказчиком, стратегию.

Уточнение бэклога (refinement)

Уточнение бэклога (product backlog refinement) — это работа, в ходе которой элементы дробят на более мелкие и дополняют деталями: описанием, порядком, размером. Раньше эту практику называли грумингом (grooming). В актуальном Руководстве по Scrum используется термин refinement.

Уточнение — не отдельное событие Scrum, а постоянная деятельность. Многие команды проводят для него регулярную встречу раз в спринт или раз в неделю, но это договоренность команды, не требование фреймворка.

Состояние, к которому ведет уточнение, описывает мнемоника DEEP (ее популяризировали Роман Пихлер и Майк Кон):

• Detailed appropriately — детальность соответствует положению: верх списка описан подробно, низ — крупными мазками;
• Estimated — элементы оценены, верхние точнее нижних;
• Emergent — список меняется по мере появления новых знаний;
• Prioritized — элементы упорядочены.

Практическое следствие: не нужно детализировать весь бэклог. Подробно описанный элемент, до которого дойдут через полгода, к тому времени устареет.

Бэклог продукта и бэклог спринта

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

	Бэклог продукта	Бэклог спринта
Кто управляет	Владелец продукта	Разработчики
К чему привязан	Цель продукта	Цель спринта
Детализация	Убывает сверху вниз	Часто до задач на день и меньше
Когда меняется	В любой момент	В ходе спринта, пока не страдает цель спринта

Бэклог спринта не «заморожен»: разработчики обновляют план по мере того, как узнают больше о работе. Если выясняется, что объем не помещается, его пересматривают вместе с владельцем продукта, сохраняя цель спринта.

Если бэклог не работает

• Список вырос до сотен элементов, в нем никто не ориентируется. Удалить то, что не поднималось наверх несколько кварталов. Важная идея вернется сама.
• Все элементы «срочные». Приоритеты заданы метками, а не порядком. Выстроить элементы в один ряд: на каждом месте стоит только один.
• Планирование спринта затягивается. Верх списка не готов. Нужно уточнение до планирования: критерии приемки и оценка хотя бы на один-два спринта вперед.
• Команда делает истории, а продукт не движется. Нет цели продукта или элементы с ней не связаны. Проверить каждый верхний элемент вопросом «как это приближает цель».
• В бэклоге только функции. Дефекты и технические работы ведутся в другом месте и конкурируют за время команды неявно. Свести всю работу над продуктом в один список.

Выводы

• Бэклог продукта — упорядоченный и постоянно меняющийся список всего, что нужно для улучшения продукта. Это не техническое задание и не план с датами.
• В Scrum за бэклог отвечает владелец продукта, размер элементов оценивают разработчики.
• Функции удобно описывать пользовательскими историями с критериями приемки в формате «Дано — Когда — Тогда», но формат элемента фреймворком не задан.
• MoSCoW, RICE и WSJF дают разный порядок на одном и том же списке: метод выбирают под вопрос, на который нужен ответ.
• Подробно описывать стоит только верх списка. Бэклог спринта — отдельный артефакт с целью и планом, им управляют разработчики.

Где применяется / связь с практикой

Работа с бэклогом — ежедневная задача менеджера продукта и владельца продукта: собрать запросы, сформулировать истории, обосновать порядок цифрами и объяснить его команде и заказчику. Те же навыки нужны аналитику и руководителю проекта, когда они готовят элементы к планированию.

Смежные темы: Scrum от А до Я.

FAQ

Сколько элементов должно быть в бэклоге продукта?
Нормы нет. Ориентир практический: владелец продукта должен быть в состоянии объяснить, зачем в списке каждый элемент и почему он стоит на своем месте.

Нужно ли оценивать элементы в story points?
Нет, это одна из возможных единиц. Руководство по Scrum требует только, чтобы размер оценивали разработчики; команды используют также размеры «как у футболок» (S, M, L) или просто считают число элементов.

Чем бэклог отличается от дорожной карты (roadmap)?
Дорожная карта показывает крупные цели и направления по периодам и предназначена для согласования ожиданий. Бэклог — рабочий список конкретных элементов, из которого команда берет работу в спринт.

Можно ли вести бэклог без Scrum?
Да. В Kanban бэклог — входная очередь перед доской, в проектной работе похожую роль играет реестр требований. Общий принцип тот же: один упорядоченный список.