Бэклог продукта: как собрать рабочую очередь

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

Бэклог отличается от дорожной карты и списка задач на спринт. Дорожная карта показывает направление продукта и значимые результаты, Product Backlog хранит возможную будущую работу, а Sprint Backlog относится только к выбранному периоду работы команды.

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

Бэклог продукта собирают вокруг цели продукта и назначают человека, который отвечает за порядок очереди. В Scrum ответственность за эффективное управление Product Backlog лежит на Product Owner; вне Scrum команда также должна явно определить владельца очереди.

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

Полезно разделять минимум два состояния работы:

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

Откуда брать пожелания к продукту

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

Команда сервиса записи на консультации получила шесть разных входящих:

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

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

Что записывать в карточке бэклога

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

Например, карточка про перенос записи уже после уточнения выглядит не как «Сделать перенос», а как конкретный ожидаемый результат:

• Проблема: клиент не способен изменить время существующей записи без обращения в поддержку. 
• Результат: клиент выбирает другой доступный слот для существующей записи. 
• Ограничение: слоты должны отображаться в часовом поясе клиента. 
• Критерий приёмки: исходная запись изменяется только после подтверждения нового времени. 
• Следующий вопрос: какие ограничения API действуют для уже оплаченных консультаций.

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

Как подготовить элементы бэклога к обсуждению

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

Для задачи о переносе записи сначала требуется понять пользовательскую проблему. После этого команда определяет ожидаемое поведение, ограничения API, возможный объём разработки и критерии приёмки. Если главный вопрос пока относится к технической возможности, первым элементом становится исследование, а не полный проект реализации.

Постоянное уточнение Product Backlog в Scrum Guide называется refinement. Термин «груминг бэклога» исторически используется для той же практики. Refinement относится к текущей работе с очередью, а не к обязательному отдельному событию с универсальной продолжительностью.

Как уменьшить слишком крупный элемент

Слишком крупный элемент уменьшают через выделение небольшого проверяемого пользовательского результата. Разбиение только по техническим слоям вроде «backend», «frontend» и «база данных» создаёт отдельные задачи, но не всегда создаёт самостоятельно проверяемую ценность.

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

Перед оценкой крупной работы команда должна разбить крупную задачу на части с понятным результатом.

Размер обсуждает команда, которая будет выполнять работу. Универсального перевода story points в часы нет: единицы оценки работают только внутри конкретной договорённости команды.

Как понять, что элемент готов к планированию

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

Для переноса записи верхняя карточка уже содержит ожидаемое поведение:

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

Критерии приёмки описывают ожидаемое поведение конкретного элемента. Definition of Done относится к качеству готового инкремента и не заменяет критерии приёмки.

Definition of Ready встречается как внутренняя договорённость отдельных команд о минимальном состоянии элемента перед планированием. Scrum не определяет DoR как обязательный артефакт.

Далёкие элементы не требуют той же детализации. Подробное описание всей очереди заранее создаёт работу, часть которой устареет раньше реализации.

Как определить порядок работ в бэклоге

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

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

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

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

Как выбирать между одинаково важными элементами

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

Представим две карточки: перенос записи и тёмная тема. Оба запроса поступали от пользователей, но у переноса уже описана проблема в основном пользовательском пути, а для тёмной темы пока не определена связь с текущей целью продукта.

Команда фиксирует не только выбранный порядок, но и основание решения:

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

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

Как учесть зависимости при выборе следующей работы

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

Запрос «снизить задержку поиска слотов» связан с API, через который система получает доступное время. До обещания большого изменения команда исследует источник задержки и определяет, находится ли проблема внутри продукта или во внешнем сервисе.

Исследование в данном случае становится отдельным элементом выше основной доработки:

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

Как поддерживать бэклог в актуальном состоянии

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

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

Частоту refinement команда выбирает по потоку изменений. Универсальной нормы по времени или количеству встреч Scrum не устанавливает.

Какие элементы объединять или отправлять в архив

Элементы объединяют при подтверждённом совпадении пользовательской проблемы, а в архив отправляют записи с утратившим актуальность основанием. Возраст карточки сам по себе не является достаточной причиной для удаления.

Для каждой старой записи последовательно проверяют:

Две заявки на перенос записи объединяются только после проверки совпадения проблемы. При объединении сохраняются оба источника, пользовательские наблюдения и дополнительные ограничения.

Интеграцию с закрытым партнёром отправляют в архив после подтверждения прекращённого партнёрства. Архивная запись сохраняет причину решения, дату и условие возврата, например возобновление договора.

Архив отличается от удаления истории. Через несколько месяцев команда должна понимать, почему работа исчезла из активной очереди и на каких данных принималось решение.

Как заметить, что бэклог перестал помогать команде

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

Основные сигналы видны в самой очереди:

• верхняя часть заполнена карточками с одинаковым приоритетом;
• у входящих пожеланий долго нет следующего действия;
• одинаковые проблемы заведены несколько раз;
• участники заново выясняют источник и причину появления карточки;
• подробные описания далёких элементов постоянно переписываются;
• срочные запросы регулярно обходят общий порядок без зафиксированного основания.

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

Как передавать элементы бэклога в работу

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

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

Годовую очередь не нужно переносить в активную колонку. В работе остаётся только объём, который команда действительно взяла на выполнение.

Что меняется при отборе элементов в спринт

При отборе в спринт выбранные элементы Product Backlog становятся частью Sprint Backlog вместе с целью спринта и планом выполнения. Developers формируют план работы и отвечают за Sprint Backlog.

Sprint Backlog не является неподвижной копией нескольких верхних карточек Product Backlog. План уточняется по мере выполнения, пока Sprint Goal остаётся ориентиром для команды.

Команде, которая использует спринты, требуется разобраться в Scrum до настройки правил отбора из продуктового бэклога.

Как вести бэклог продукта в Strive

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

Для учебного процесса достаточно трёх состояний:

Названия колонок относятся к предлагаемой конфигурации, а не к обязательному штатному процессу Strive. Команда настраивает этапы под собственный способ работы.

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

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

Как настроить доску для разбора бэклога

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

Для сервиса записи на консультации доска выглядит следующим образом:

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

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

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