Что такое бэклог простыми словами и кто его ведёт

Вячеслав Степанов — проджект-менеджер, ментор · 30 сентября 2026

«Закинь в бэклог», «это лежит в бэклоге полгода», «сначала разберём бэклог» — слово звучит в IT-команде каждый день. От того, в каком состоянии бэклог, зависит, пройдёт ли планирование за час или растянется на полдня. Ниже — что такое бэклог, чем бэклог продукта отличается от бэклога спринта, откуда в нём берутся задачи, кто его ведёт и как не дать ему превратиться в свалку. Видео-версия — мой открытый урок про груминг, то есть уход за бэклогом.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое бэклог

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

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

В Scrum Guide — официальном руководстве по Scrum от Кена Швабера и Джеффа Сазерленда — бэклог продукта описан как упорядоченный и постоянно меняющийся список того, что нужно для улучшения продукта. Это единственный источник работы для команды: если задачи нет в бэклоге, команда её не делает.

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

В Scrum бэклогов два, и новички их часто путают.

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

В Kanban спринтов нет, и бэклог — это просто первая колонка доски слева. Задачи оттуда забирают в работу по мере того, как освобождаются люди.

Что лежит в бэклоге и откуда берутся задачи

Элементы бэклога бывают разного размера и типа: эпики (крупные направления вроде «Telegram-бот»), пользовательские истории, отдельные задачи, баги, технический долг. Подробнее о типах задач — в статье про Jira и Confluence.

• Исследования продакт-оунера. Он общается с пользователями, проверяет гипотезы и приносит проработанные фичи с понятной ценностью.
• Отзывы с демо. Стейкхолдеры смотрят результат спринта и говорят «а ещё хочется вот это». Хотелка на будущее — в бэклог.
• Баги. Некритичные ошибки не чинят срочно, а кладут в бэклог и берут в один из следующих спринтов.
• Технический долг. Разработчики заводят задачи на то, что сделали на скорую руку и что нужно переделать.
• Решения ретроспективы. Каждый пункт плана действий становится задачей — подробнее в статье про ретро.

Кто ведёт бэклог

По Scrum Guide за бэклог продукта отвечает продакт-оунер (Product Owner) — и это всегда один человек, не комитет. Он формулирует цель продукта, решает, какие задачи попадают в бэклог и в каком порядке их делать. Часть работы он может поручить другим, но ответственность остаётся на нём.

У остальных — свои роли:

• Команда разработки оценивает задачи, дробит крупные на мелкие и задаёт вопросы, пока задача не станет понятной.
• Проджект-менеджер следит, чтобы бэклог был в рабочем состоянии: заводит баги и задачи по итогам демо и ретро, готовит и ведёт груминг, проверяет, что у верхних задач есть описание и критерии приёмки. Порядок задач он не меняет сам — это решение продакт-оунера.

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

Как расставляют приоритеты

Когда задач больше, чем команда успеет сделать, — а так бывает почти всегда, — продакт-оунер опирается на фреймворки приоритизации. Три самых распространённых:

• MoSCoW — делит задачи на четыре группы: Must (обязательно), Should (желательно), Could (можно, если останется время), Won't (не сейчас). Удобен для первого быстрого среза.
• RICE — считает балл по формуле: охват × влияние × уверенность ÷ усилия. Подходит для крупных решений, где нужно сравнить фичи в цифрах.
• ICE — влияние × уверенность × простота. Упрощённый вариант RICE для быстрой оценки.

Какой бы способ ни выбрали, итог один: у каждой задачи своё место в списке. Если в бэклоге двадцать задач с пометкой «самый высокий приоритет», приоритетов в нём на самом деле нет.

Как ухаживать за бэклогом

Хороший бэклог описывают правилом DEEP — его предложил Майк Кон, один из авторов гибких методологий:

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

Держать бэклог в таком состоянии помогает груминг (backlog refinement) — регулярная встреча, на которой команда разбирает задачи следующего спринта: уточняет смысл, добавляет критерии приёмки, дробит крупное, ставит оценки. В Scrum Guide уточнение бэклога описано как постоянная работа команды, а не отдельное событие с жёстким временем. На практике многие команды проводят груминг раз в спринт, примерно на час.

Задача считается готовой к спринту, когда проходит Definition of Ready — договорённость команды: понятен смысл, есть критерии приёмки, есть оценка, нет открытых вопросов.

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

Полезная привычка — прикинуть, сколько спринтов займёт текущий бэклог. Если команда стабильно закрывает 8 задач за спринт, а в бэклоге 24, понадобится около трёх спринтов. Расчёт грубый, но сразу показывает, что влезет в квартал. А если бэклог растёт быстрее, чем команда его разбирает, — это сигнал для разговора о приоритетах.

Как бэклог выглядит в Jira

В Jira у Scrum-проекта есть отдельный раздел Backlog. Сверху — блоки спринтов, текущего и будущих, снизу — общий бэклог продукта. Задачи перетаскивают мышкой: вверх-вниз, чтобы поменять порядок, и в блок спринта, чтобы взять их в работу. Там же видно оценки и эпики, к которым относится задача.

В Kanban-проекте бэклог выглядит как первая колонка доски, из которой задачи двигаются слева направо по статусам.

Типичные ошибки

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

Частые вопросы