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

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

Обычно подобные методики применяются в работе с командой разработки, когда разрабатываются какие-то IT-продукты и сервисы, но можно внедрять и в обычных командах. Я, в логистике, помню, настраивал работу склада по Scrum

Один из максимально удобных инструментов для ведения бэклога - Jira. Можно настроить и Asana и Notion. Но, Jira, субъективно удобнее. Я опишу Jira, а вы сможете в работе сравнить и выбрать самостоятельно.

• До 10 пользователей бесплатно. Доступны все необходимые и основные фичи
  
• Удобное разделение на спринты, типы задач, наглядная приоритетность и Story Point'ы.
  
• Общее пространство для работы
  
• Фильтрация по исполнителям
  
• Обсуждение задачи прямо внутри в комментариях
  
• Возможность трекать время (если пользуетесь)
  

Ведение бэклога удобно делать недельным спринтами.

1. Готовишь к следующему спринту задачи, которые нужно выполнить заранее.
   
2. На еженедельной встрече обсуждаете детали, ресурсы, ограничения, возможности. Утверждаете что будет сделано
   
3. Отслеживаешь результат
   
4. Если команда двигается быстрее ожидаемого, тот кто освободился может взять приоритетную задачу из бэклога. Поэтому задачи в бэклоге также должны быть приоритезированы.
   

Можно ввести два уровня для задач:

• Эпик. Проект/задача, которая занимает много времени, вовлекает разные отделы, команды, разделяется на множество задач.
  
• Задача. Обычные задачи, которые можно выполнить в рамках одного спринта.
  

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

1. Тип задачи
a. Стори - задача, в рамках которой пользователь получает новый функционал продукта, новый интерфейс, новые сценарии использования
b. Баг - ошибка в существующем функционале
c. Таска - внутренняя задача.
2. Приоритетность
3. Стори поинты - предварительная оценка длительности выполнения задачи

Product owner'у важно понимать какие задачи относятся к одной из этой категории:

• Бизнес-задача. Влияет на достижение поставленных целей бизнеса, выручку и ключевые показатели
  
• Техническая задача. Улучшает архитектуру, стабильность, производительность системы
  
• Баги
  

Рекомендация уделять этим задачам время в следующих пропорциях:

• Бизнес - 50%
  
• Технические - 30%
  
• Баги - 20%
  

Этапы выполнения задачи можно выставить следующие:

• To do - необходимо сделать
  
• Blocked - заблокированные задачи. Те задачи, которые были взяты в работу, но по каким-то причинам не могут быть выполнены.
  
• In Progress - в работе
  
• In Review - задачи которые в настоящий момент проверяются другими разработчиками, тестировщиками или продакт менеджером (продакт оунером)
  
• Ready to deploy - задачи прошедшие все внутренние тесты и готовые к релизу
  
• Done - выполненные задачи
  

Задачу формулировать по трем пунктам:

1. Story. История пользователя. Что он должен получить на выходе. При этом не уходить в технические детали, не дробить на фронт и на бэк, но описать основные характеристики, поля, приложить макеты, эскизы и т.д.
   
2. Business Benefits. Какие результаты принесет выполнение задачи для бизнеса, на какие ключевые показатели бизнеса мы влияем
   
3. Acceptance Criteria. Раздел в котором необходимо детально описать с какими сценариями столкнется эта функция. Можно предположить как вы будете тестировать ее, какие варианты будете прогонять прежде чем принять задачу.