Бэклог — это упорядоченный список задач и требований к цифровому продукту, который ведёт к улучшению этого самого продукта. Фактически это список функций, где задачи по их реализации расставлены в порядке приоритета. Список может дополняться и меняться по ходу проекта. Это один из ключевых элементов в Agile — он используется в Scrum и Kanban.
Представь себе, что все идеи по проекту или продукту собираются, как книги в шкафу. И этот шкаф как по волшебству выдаёт тебе книги, которые нужно прочитать именно сейчас — потому что они принесут больше всего пользы.
В разработке такое волшебство помогает творить бэклог. Он формирует список того, что надо сделать в первую очередь.
Бэклог должен быть упорядочен. Для совершенствования продукта можно придумать миллион фич, но среди них будут важные, второстепенные и просто «хотелки». Задача бэклога именно как инструмента управления — приоритизировать и наводить порядок.
Есть бэклог продукта и бэклог спринта.
- Бэклог продукта — полный перечень требований к продукту. Это основа для достижения долгосрочных целей.
- Бэклог спринта — перечень задач на пути к достижению краткосрочных целей во время спринта (1–4 недели).
За бэклог продукта отвечает владелец продукта (Product Owner), а бэклог спринта формируется вместе с командой. А за реализацию последнего отвечает проджект или продакт.
Не пропусти наш подробный гайд по организации бэклога в WEEEK двумя способами
👍🏻 Сформировать свой бэклог можешь по готовому шаблону от WEEEK для организации работы по Scrum. Чтобы начать работу с ним, зайди в рабочее пространство, найди раздел «Шаблоны» внизу слева, добавь шаблон себе — всё, можешь использовать его
Структура бэклога
Стандартного содержания бэклога нет — конкретный бэклог в отдельно взятой компании формируется в зависимости от особенностей продукта, команды, методов управления и сроков.
Но бэклог нельзя назвать бэклогом без двух основных составляющих: задачи и приоритет. Эти элементы есть всегда.
Простейший вариант бэклога — список фич в порядке реализации, но это редкость. Чаще всего там присутствуют и другие типы задач: исправление ошибок, доработка интерфейса, проведение интервью или исследований. И каждая задача может быть расписана подробно — обычно, чем сложнее идея, тем подробнее она описана.
В структуре бэклога встречаются вот такие элементы:
- Требования к продукту. Это функциональные характеристики.
- Истории пользователей, или User story. Пользовательские истории — это тоже функциональность продукта, но описанная с точки зрения пользователей. Истории потом разбиваются на конкретные задачи.
- Баги. И задачи на исправление ошибок. Выделяют три вида багов: срочные (они часто даже не успевают попасть в бэклог, потому что исправляются асап), спринт-баги (берутся в работу в течение текущего спринта), баги продукта (не влияют на работу в текущем спринте, идут в бэклог продукта).
- Оценка сложности. Это или количество часов, которые нужны на выполнение задачи, или условная единица измерения — Story Point.
- Сроки. Особенно важно для бэклогов спринтов.
- Технический долг. Появляется из-за переноса задач из предыдущего спринта или из-за ошибок в планировании. Когда времени не хватило и пришлось переносить.
- Инициатор или владелец задачи. Речь не только об исполнителе. Порой через несколько месяцев после старта проекта сложно вспомнить, а кто, собственно, придумал красные кнопки в приложении.
- Статус. Как вариант — маркеры приоритетов или теги. Статус позволяет быстро отфильтровать и найти задачи в разросшемся бэклоге.
- Дополнительные данные. Артефакты, информация, референсы, выдержки из интервью с пользователями — всё, что поможет выполнить задачу.
Бэклог можно сделать в форме классической таблицы с колонками и строками, либо собрать на Канбан-доске. Например, как бэклог идей — он структурирует гипотезы и задачи из них. Каждая идея проверяется, оформляется в гипотезу, которая проходит первичную проверку, берётся в работу в виде задачи, переносится в колонку «К работе».
Чтобы показать, как выглядит бэклог, я придумала разобрать планы Альбуса Дамблдора. Давай представим, что он многое знал наперёд и составил бэклог проекта по уничтожению Тёмного Лорда.
Что мы видим из этого бэклога? Что многое приходится корректировать, что не всё удаётся сделать без проблем, что баги — неизбежная сторона жизни.
Зачем нужен бэклог на проекте
- Бэклог — основа декомпозиции. Он заменяет громоздкие техзадания, огромный план проекта и сводит эти массивные документы до одной ясной задачи. Техзадания могут быть непонятными и большими, а бэклог — лёгкий срез всего массива требований.
- Структурирует работу. Это и довольно чёткий план, и понимание, что делать в первую очередь, и прозрачное видение будущего проекта.
- Держит в тонусе развитие продукта. Поскольку с бэклогом надо работать проактивно — менять его, дополнять, — то он как бы сам провоцирует к рефлексии на тему: «А что можно сделать лучше?»
- Экономит время. И так со всеми планами 🙂 Участники проекта видят список задач в бэклоге в порядке приоритета. В спринтах план обычно формируется аж на четыре недели, так что все участники команды знают, что они будут делать завтра. И не хотят уточнить.
Как правильно приоритизировать бэклог
Расставь задачи в бэклоге по приоритету! А как?
На практике всё довольно субъективно. Как-то надо учесть и важность, и сложность. Владелец продукта считает, что нужно сделать кабинет клиента, добавление в избранное и заодно перестроить логику оплаты. А разработчики умрут под шквалом таких супер-важных и объёмных задач.
Инструменты приоритизации, описанные ниже, помогут решить эти вызовы.
Story mapping
сложность ⭐⭐⭐⭐
субъективность ⭐
другие методы приоритизации: ✅ пригодятся для оценки сложности фич
синхрон с командой: ✅ обязательно
Этот метод «идёт» от пользователя: здесь нужно составить историю взаимодействия юзера с продуктом. Ищет товар ➡️ делаем поиск; смотрит товар ➡️ делаем карточку и фото; добавляет в корзину ➡️ делаем корзину. И так далее. Задачи ставятся и распределяются в порядке пути пользователя.
MoSCoW
сложность ⭐
субъективность ⭐⭐⭐⭐
другие методы приоритизации: ✅ нужны
синхрон с командой: ✅ обязательно
Достаточно простой способ приоритизировать бэклог по четырём критериям:
- M, Must Have — ключевые функции продукта, которые обязательно надо сделать (условно, это идёт в бэклог ближайшего спринта)
- S, Should Have — функции, которые должны быть реализованы, но их можно отложить или обойтись без них (идут в бэклоги будущих спринтов на квартал, их со временем надо пересмотреть)
- C, Could Have — функции, которые хорошо бы сделать (уходят в бэклог продукта)
- W, Would Have — функции из разряда «хотелок» и дополнений. Они не особо влияют на функциональность продукта (лежат в бэклоге продукта, могут быть никогда не сделаны, а могут быть реализованы, если не займут много времени)
Value and Efforts
сложность ⭐⭐
субъективность ⭐⭐⭐
другие методы приоритизации: ✅ пригодятся, но не обязательно
синхрон с командой: ✅ обязательно
Строим график по двум шкалам — значимость и усилия.
Значимость — важность функций или зависимость бизнес-показателей.
Усилия — это, к примеру, человеко-часы.
Сначала закрывают простые и значимые задачи, следом — сложные и значимые, а затем всё остальное. Субъективность ниже, так как вы с командой можете опереться на требования бизнеса и понимание, сколько сил нужно на разные задачи.
ICE Scoring
сложность ⭐⭐⭐
субъективность ⭐⭐
другие методы приоритизации: необязательно
синхрон с командой: ✅ обязательно
ICE Scoring — это оценка по трём параметрам:
- Impact — влияние на продукт с точки зрения бизнеса
- Confidence — уверенность в оценке важности
- Ease — трудозатраты на реализацию
Каждый из параметров оценивается по шкале от 1 до 10, потом полученные значения перемножаются между собой. В итоге у нас условное число, которое даёт оценку задаче. Чем больше, тем выше приоритет.
5 советов по работе с бэклогом
- За бэклог отвечает владелец продукта. Идеи и задачи могут накидывать все члены продуктовой команды, но именно владелец продукта определяет последовательность работы (хотя в связке с командой, об этом ниже). Мнение владельца продукта важно и во многом определяющее, поскольку именно он анализирует информацию о рынке и курирует общий вектор развития продукта.
- Бэклог должен быть понятным. В нём можно использовать специальные термины, но будь осторожнее с локальными фразами, аббревиатурами и сленгом, если команда большая и разная.
- Бэклог должен обновляться. Это гибкий инструмент, который нужно адаптировать к изменениям. Актуализация бэклога — это груминг, он включает: удаление лишних элементов, уточнение текущих, добавление новых, декомпозицию крупных задач, корректировку оценок и приоритетности, группировку по смыслу.
- Бэклог должен быть доступным. Нет стандарта ведения бэклога: кто-то это делает в блокноте или на доске; кто-то использует цифровые программы. Важно, чтобы команда могла найти его.
- Бэклог лучше формировать на базе пользовательских историй. User Story — то, что позволит реализовывать востребованный продукт и грамотно приоритизировать бэклог.
Основные ошибки при работе с бэклогом
- Бэклог формируется только владельцем продукта. Мнение владельца продукта может быть субъективным, или его решения вынудят команду работать сразу над множеством сложных и важных задач. Следует использовать дополнительные способы приоритизации — которые, в том числе помогут оценить сложность работы.
- Бэклог не обновляется. Без активной работы по бэклогу можно отстать от конкурентов или создать нежизнеспособный продукт.
- Слишком большой бэклог. Научи команду выкидывать из бэклога старые идеи. Если им больше трёх месяцев, но в план спринта они так и не попали — то всё. Груминг бэклога проводите регулярно, в идеале — после каждого спринта.
- Бэклог записан в нескольких местах. Одна задача записана в трекере, вторая в другом трекере, третья — на листочке. Такой бэклог только путает команду: нужно выбрать одно место для формирования бэклога и работать в нём.
- Узкоспециальные названия и термины захватывают бэклог. Я копирайтер и редактор, но работаю над проектами, связанными с IT. Бэклог у нашей команды общий! И если разработчики будут использовать там сленг и узкопрофильные термины, это сильно усложнит работу остальным (таким, как я) или может привести к ошибкам.
Организуй бэклог задач вместе с WEEEK
Мы распишем тебе один из стандартных способов создания бэклога в WEEEK с помощью Канбан-досок.
- Внутри проекта «Разработка мобильного приложения» делаем доску «Бэклог продукта».
- Бьём доску на четыре колонки — каждая на один квартал календарного года.
- Формируем список идей — функций мобильного приложения. Записываем их все пока что подряд, в одну колонку.
- Прогоняем через способы приоритизации. Подойдёт Story mapping и MoSCoW.
- Должен получиться бэклог продукта, приоритизированный по кварталам.
- Формируем бэклог спринта. Забираем одну-две карточки из доски с квартальными планами и перетаскиваем в доску «Бэклог спринта».
- Эти карточки ещё декомпозируем. Задача «Сделать каталог» объёмная, так что бьём её на части — собрать контент для карточек товаров, подготовить структуру, проработать логику и так далее.Карточки из бэклога продукта можно декомпозировать с помощью подзадач. Эти подзадачи ты в пару кликов перенесёшь в колонку «В работе». Каждую подзадачу ты всегда можешь отвязать от родителя и сделать самостоятельной единицей.
- Прогоняем через способы приоритизации. Подойдут Value and Efforts и ICE Scoring.
Расставляй задачам сроки выполнения и исполнителей. Внутрь всегда можешь добавить артефакты.
Доски спринтов ты можешь озаглавить вот так: «Спринт 10.10 — 10.11» — то есть указав в названии сроки текущего спринта. Советуем сохранять доски прошедших спринтов для ретроспективы.
Используй готовые шаблоны WEEEK для организации работы с бэклогом по Scrum. Также у нас есть шаблон для web-разработки. Чтобы начать работу с шаблоном, зайди в рабочее пространство, найди раздел «Шаблоны» внизу слева, добавь шаблон себе — всё, можешь использовать его
Подписаться 
