Бэклог пухнет от сотен тикетов, а Разработчики не понимают, за что хвататься. Стейкхолдеры кидают идеи в чат, и они тут же получают статус «Срочно». Прекратите превращать Product Backlog в мусорную корзину и настройте жесткий фильтр на входе.
Где заканчивается фантазия и начинается работа
Scrum Guide 2020 определяет Product Backlog как упорядоченный список всего, что нужно для улучшения продукта. Это не значит, что туда попадает любая фантазия заказчика. Единственный фильтр — Product Goal (Цель Продукта). Владелец Продукта (Product Owner) убивает идею на месте, если она не бьет в эту цель.
Выжившие гипотезы отправляются на Product Backlog Refinement (уточнение). Разработчики дробят крупные куски, выявляют технические зависимости и дают оценку. Тикет становится реальной задачей только тогда, когда команда четко понимает, как превратить его в рабочий Инкремент. До этого момента это просто текст на экране.
Таблица
| Этап жизни идеи | Действие команды | Артефакт / Инструмент |
|---|---|---|
| Вброс идеи | PO проверяет гипотезу на адекватность и соответствие метрикам. | Product Goal |
| Refinement (Уточнение) | Разработчики задают вопросы, режут фичу на части, дают оценку. | Product Backlog |
| Подготовка к Спринту | Фиксация критериев приемки, снятие внешних блокеров. | Definition of Ready (DoR) |
Как это работает на практике
Создайте воронку идей до бэклога. Настройте отдельную доску или статус для сырых запросов. Не пускайте их в основной Product Backlog, пока PO не проведет первичный анализ ценности.
Задавайте жесткие вопросы. Кто целевая аудитория? Какую метрику качаем? Отклоняйте тикеты без доказанной бизнес-ценности. Майк Кон учит: если вы не можете написать User Story с понятным «чтобы что», задачу делать не нужно.
Проводите Refinement регулярно. Выделяйте время в каждом спринте. Разработчики читают тикет, ищут зависимости и пишут приемочные тесты.
Оценивайте сложность сразу. Используйте Planning Poker или Story Points. Вытащили карту с 20 баллами — рубите фичу на три мелкие задачи. Огромные тикеты убивают предсказуемость спринта.
Главная мысль
Бэклог — это не склад забытых обещаний, а сфокусированный план атаки. Владелец Продукта обязан защищать команду от информационного шума. Учитесь говорить «нет», иначе ваш идеальный процесс захлебнется в потоке бесполезного кода.
Часто задаваемые вопросы (FAQ)
За Бэклог Продукта отвечает исключительно Владелец Продукта. Стейкхолдеры и Разработчики могут предлагать идеи, но финальное решение о добавлении и приоритизации тикета принимает только PO.
Разработчики заводят тикеты на рефакторинг или обновление инфраструктуры. Владелец Продукта приоритизирует их наравне с бизнес-фичами. Покажите бизнесу стоимость задержки (Cost of Delay), чтобы обосновать трату времени на техдолг.
Нет. Баг — это баг. Опишите шаги для воспроизведения, ожидаемый и фактический результат. Не тратьте время на натягивание шаблона «Как пользователь, я хочу…» на упавший сервер.
Ровно столько, чтобы хватило на 2-3 спринта вперед. Держите бэклог коротким. Задачи, которые лежат там полгода, протухли. Смело удаляйте их.
Никак. Владелец Продукта сам вытаскивает из них суть через интервью и переводит в формат гипотез. Стейкхолдер приносит проблему, а PO и Разработчики придумывают решение.