Бэклог продукта не может быть завершенным, поскольку он динамически меняется и постоянно улучшается.
Единого формата ведения бэклога нет. Бэклог команды может быть представлен:
электронными таблицами;
обычной доской в офисе компании;
специализированной программой.
Чтобы собрать бэклог продукта, потребуется:
Составить список функций. По возможности сразу задать приоритеты.
Прописать пользовательские истории для каждого выдвинутого предложения. На этом этапе проводится анализ ценности.
Расставить компоненты, прошедшие отбор, согласно приоритетам. Их нужно записать в backlog.
Обсудить предстоящие работы с командой – кто как понял цели, функции и способы реализации. Здесь предстоит назначить ответственных лиц и определить сроки, отведенные на воплощение задумок в жизнь.
По мере завершения задач проводить их обновления.
Чтобы бэклога продукта оставался актуальным, к нему нужно регулярно возвращаться. По мере разработки и обновления ПО некоторые задачи потеряют значимость, зато образуются новые. Отслеживание рассмотренного компонента – это ускорение релиза с минимальными затратами на совершенствование продукции в будущем.
Что делать, если бэклог неустанно растет?
Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать.
Чтобы бэклог не увеличивался можно сделать следующие вещи:
- Структурирование бэклога по этапам для идей:
Collect Ideas — для сбора всех идей.
Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
Score Ideas — для оценивания идеи.
Approval — для проверки идеи Scrum-мастером или менеджером проекта.
Developing — для отправления идеи в разработку.
Done — для реализованных идей. Это означает, что функция «залита» на продакшн.
- Оценка идей по принципу Value and Efforts
Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.
Value показывает, какую бизнес-ценность может принести ваш продукт или бизнес.
Efforts измеряют ресурсы, необходимые для выполнения задачи.
- Backlog Priority Chart
Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:
Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
Big Bets для идей, имеющих большие ценность и усилия.
Maybes для идей с низкими ценностью и усилиями.
Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.
Критерии приёмки (Acceptance Criteria) — специфические требования и приёмочные тесты, которым должны соответствовать элементы бэклога продукта, чтобы работа по ним считалась завершённой с точки зрения клиента / владельца продукта. Определение критериев приёмки звучит очень похоже на критерии готовности, но в действительности эти понятия отличаются: критерии приёмки касаются требований клиента к конкретному элементу бэклога, а критерии готовности формируются командой и касаются многих элементов.