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

Всем привет, я Ваня, из команды продукта SimpleOne SDLC. Поговорим с вами о том, как бэклог превращается в свалку, почему RICE и WSJF звучат красиво, но редко приживаются, и что на самом деле помогает держать бэклог управляемым.

Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.

Почему бэклог растет — и почему это плохо

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

Типичный разговор перед планированием: 

— Эту задачу можно закрыть, она висит с февраля? 

— Нет-нет, это стратегически важно.

— Кто поставил? 

— Вася. Он уволился в апреле. 

— Тогда закрываем?

— Нет, все-таки лучше не трогать.

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

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

RICE, WSJF, MoSCoW — про них пишут много, используют редко

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

Грумминг в дикой природе:

— Почему эта фича в топе спринта? 

— Продуктовый маркетолог попросил. 

— А задача поддержки, которая блокирует 20 клиентов? 

— Ну она не срочная… 

— По чьей методологии? 

— По ощущениям.

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

Есть и другая проблема: ценность у всех разная. Где-то это выручка, где-то — количество довольных клиентов, где-то — скорость закрытия инцидентов. Как посчитать «довольный заказчик» в цифре? Правильного ответа нет. А значит, любая формула в итоге подгоняется под субъективное ощущение нужного человека.

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

Поэтому лучше стремиться не к универсальному фреймворку, а к собственной метрике ценности — той, которая отражает реальные приоритеты именно вашей компании. Поэтому в SimpleOne SDLC, например, нет встроенного фреймворка приоритизации, но есть поле «ранг», которое владелец продукта расставляет сам.

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

Три уровня бэклога: продуктовый, командный, спринтовый

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

Продуктовый бэклог — верхний уровень

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

Командный бэклог — следующий уровень

Из продуктового сюда «спускаются» задачи, которые конкретная команда будет делать в обозримом горизонте. Здесь уже появляется декомпозиция: пользовательские истории, задачи, работы.

Спринтовый бэклог — низкоуровневые задачи на две-четыре недели

Бэкенд, фронтенд, конкретные доработки. Важный нюанс: этот уровень не высекается в камне. Суть спринта — достичь цели. Если несколько задач не успели, но цель закрыта, то все нормально.

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

Схожую логику можно найти в разных методологиях — в SAFe это корпоративный портфель → портфель ART → командный бэклог, в Scrum — Product Backlog → Sprint Backlog. Названия разные, но суть похожая.

Классика жанра:

— Зачем мы делаем эту задачу? 

— Написано же: «улучшить UX». 

— Это к какому эпику? 

— Не привязана. 

— К какому релизу? 

— Тоже нет. 

— Тогда откуда она вообще взялась? 

— Хороший вопрос… 

— Архивируем? 

— Нет, давай оставим. Вдруг важное.

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

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

Практика показывает: лучше всего работают два подхода

Ограниченный бэклог

Примерно 20 задач, которые команда хорошо понимает и планово берет в работу. Рядом существует отдельный список идей и гипотез — сырых, без статусов и сроков. Это именно список, а не задачи. Когда бэклог заканчивается, смотришь в идеи и решаешь, что из них стало актуальным. Минус — стейкхолдеры в B2B-продуктах не всегда понимают, что такое «идея без дедлайна», и начинают нервничать.

Единый бэклог, разбитый на модули

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

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

А надо ли автоматизировать груминг?

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

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

Есть и другой аргумент против автоматизации: часть дефектов, которые годами лежат в бэклоге, уже исправлена — просто в рамках другой задачи. Никто не закрыл старый тикет. Автоматика это не поймет.

Если бэклог уже сломан — не чините, начните заново

Открываете новый проект, переносите туда только то что реально актуально прямо сейчас. Старое оставляете как архив — поисковик найдёт если понадобится. Это быстрее и честнее чем пытаться разгрести тысячу задач по одной.

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

Не создавать задачи «на потом», не фиксировать каждую идею как тикет, держать идеи отдельно — просто списком, без статусов и сроков. Когда пришло время — перевести в задачу. Не пришло — пусть остается гипотезой. Создал задачу «интеграция с GitHub» → прошло четыре года → ввели ограничения для российских пользователей. И что теперь с этой задачей?

Это, конечно, идеальный мир. Но именно так работают команды, у которых бэклог остается управляемым: в реальной работе одновременно в процессе находится 10–15 задач — это уже немало. Добавлять к ним хвост из 400 «важных, просто не сейчас» — значит размывать фокус у всей команды.

Резюме

Бэклог превращается в свалку не потому что команда ленится — а потому что нет культуры его ограничения. Фреймворки приоритизации вроде RICE и WSJF логичны, но дорого стоят в поддержке и редко приживаются надолго. Трехуровневая структура — продуктовый, командный, спринтовый — помогает не терять связь между стратегией и конкретной задачей. А лучший груминг — это тот, который не нужен: не давать бэклогу расти, держать идеи отдельно от задач, работать с тем, что действительно актуально прямо сейчас. 

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

***

А как у вас устроен бэклог? Используете какой-то фреймворк приоритизации — или в итоге все равно расставляете руками?