Product Backlog
Product Backlog — главный артефакт Scrum, единый источник истины «что может попасть в продукт». В нём:
- Пользовательские истории (User Stories)
- Эпики
- Баги
- Технический долг и рефакторинг
- Исследования (Spike)
Backlog упорядочен сверху вниз: самое приоритетное — наверху. Чем выше элемент, тем подробнее он должен быть описан (Definition of Ready). Низ бэклога может быть «грубым» — это нормально.
За backlog отвечает Product Owner: он его пополняет, переупорядочивает и решает, что брать в следующий спринт. Команда участвует в Backlog Refinement — встречах, на которых уточняются истории, ставятся оценки и разбиваются крупные задачи.
Когда применять и когда нет
Применять
- Работаете по Scrum или Scrumban
- Нужен один источник всех потенциальных задач продукта
- Хотите видеть приоритеты в одном месте
Не применять
- В Kanban-командах часто используют просто колонку «Бэклог» без формального Product Backlog
- Если нет PO, который активно ведёт приоритизацию — backlog превратится в свалку
Примеры применения
В Shtab Product Backlog — это вид «Список» с фильтром «Задачи без спринта» и сортировкой по приоритету. PO перетаскивает истории по приоритету, на Sprint Planning команда берёт верхние в Sprint Backlog.
Часто задаваемые вопросы
Product Backlog — все потенциальные задачи продукта, упорядоченные по приоритету. Sprint Backlog — подмножество, которое команда взяла на текущий спринт.
Формально — Product Owner. Но идеи могут приходить от команды, стейкхолдеров, поддержки, аналитики. PO решает, добавлять ли их и с каким приоритетом.
Минимум — раз в спринт перед Sprint Planning. На практике PO корректирует приоритеты постоянно, по мере поступления новой информации.