Из чего состоит Backlog?

Структура Product Backlog: компоненты и организация

Backlog — это упорядоченный список всех требований, функций, улучшений и задач, которые нужно реализовать в продукте. В Agile-методологии это главный источник истины о том, что нужно построить. Business Analyst часто отвечает за управление backlog.

Основные компоненты Backlog

1. User Stories (Пользовательские истории)

Это основная единица backlog. User Story описывает требование с точки зрения конечного пользователя.

As a Customer
I want to filter products by price
So that I can find items in my budget

Acceptance Criteria:
- Filter shows prices from 0 to 100000 rubles
- Results update in real-time without page reload
- Filter persists when navigating between pages

Характеристики User Story:

• Небольшая, реализуемая за 1-3 спринта (3-13 story points)
• Имеет чёткий результат (Definition of Done)
• Независима от других историй по возможности
• Проверяема (есть acceptance criteria)

2. Features (Функции)

У крупные требования, которые состоят из нескольких User Stories.

Фича: "Система рекомендаций"
Состоит из User Stories:
- Как пользователь, я хочу видеть рекомендации на странице товара
- Как пользователь, я хочу получать рекомендации по email
- Как администратор, я хочу управлять алгоритмом рекомендаций

Когда использовать Features:

• Разбивка большого проекта на управляемые части
• Планирование на квартал или год
• Управление зависимостями между большими блоками работы

3. Epics (Эпики)

Это самые крупные блоки работы. Эпик объединяет несколько Features и может занять несколько месяцев.

Эпик: "Персонализация пользовательского опыта"
Содержит Features:
- Система рекомендаций
- Сохранение предпочтений пользователя
- История просмотров
- Умное поиск на основе истории

Когда использовать Epics:

• Стратегические инициативы
• Планирование на год вперёд
• Связь с OKR компании

2. Технические задачи (Technical Tasks)

Не все, что нужно сделать, — это User Stories. Есть работа, которая не приносит прямой пользователь:

- Рефакторинг старого кода
- Обновление зависимостей
- Оптимизация базы данных
- Внедрение CI/CD pipeline
- Миграция на новую архитектуру

Правило: технические задачи должны быть минимальны. Если она занимает более 10% спринта, это признак архитектурных проблем.

3. Bug Reports (Отчёты об ошибках)

Ошибки в существующей функциональности, которые нужно исправить.

Bug: Пользователь не может выйти из аккаунта на мобильном
Severity: High (блокирует использование)
Steps to reproduce:
1. Открыть на мобильном
2. Нажать меню → выход
3. Кнопка не реагирует

Приоритизация bugs:

• Critical: система упала, деньги потеряны, безопасность скомпрометирована
• High: функция не работает, но есть workaround
• Medium: функция работает, но с неудобством
• Low: косметические проблемы

4. Improvement Tasks (Улучшения)

Развитие существующей функциональности, не новая фича.

Improvement: Увеличить производительность поиска
Текущее время поиска: 2 секунды
Цель: < 500 миллисекунд

5. Research & Spikes (Исследования)

Задачи, где результат неизвестен. Нужны, чтобы принять решение.

Spike: "Исследовать, какой платёжный сервис выбрать"
Цель: провести сравнение Stripe vs 2Checkout vs Yandex.Kassa
Должно включать: комиссии, API, поддержка, время интеграции

Правило: Spike не имеет story points (его объём неизвестен). Дай ему time-box: 1-2 дня.

6. Debt Items (Технический долг)

Рекогниция проблем, которые нужно исправить, но они не критичны.

Debt: "Есть сложный модуль с низкой тестовой покупкой, нужна рефакторизация"
Пакостное воздействие: медленная разработка новых фич в этом модуле

Структура и организация Backlog

Иерархия (сверху вниз)

Vision / Mission
    ↓
OKR (квартальные цели)
    ↓
Epics (инициативы)
    ↓
Features (функции)
    ↓
User Stories (задачи для спринта)
    ↓
Acceptance Criteria (детали реализации)

Состояния задач в Backlog

1. Backlog (новая, не для спринта)
2. Ready for Sprint (подготовлена, может быть взята в спринт)
3. In Sprint (взята в текущий спринт)
4. In Progress (разработчик работает)
5. In Review (код на ревью)
6. Done (сделано, проверено)
7. Cancelled (отменено, не нужно)

Правила организации хорошего Backlog

1. Приоритизация

• Самые важные задачи сверху
• Переоцениваются каждую неделю
• Выравнивается со стратегией компании (OKR)

2. Granularity (детализация)

• User Stories в backlog: 3-13 story points (реализуемы за спринт)
• Более крупные требования: разбей на несколько Stories
• Не должно быть историй < 1 point (слишком мелкие)

3. Чистота Backlog

• Удаляй дубликаты
• Удаляй obsolete требования (которые больше не актуальны)
• Архивируй старые задачи (которые решили 6+ месяцев назад)

4. Dependencies (зависимости)

• Отмечай, какие задачи зависят друг от друга
• Старайся минимизировать зависимости (они замедляют спринт)
• Если зависимость критична, она должна быть в одном спринте

5. Acceptance Criteria

• Каждая User Story имеет 3-5 criteria
• Criteria пишутся на бизнес-языке, не техническом
• Criteria проверяемы (можно сказать да или нет)

Размер Backlog

Product Backlog (весь)

~200-500 строк (на 6-12 месяцев вперёд)

Sprint Backlog (текущий спринт)

~30-50 story points на команду из 5-7 человек

Backlog Grooming

Отдельные встречи (1-2 часа в неделю) для подготовки backlog:

• Переписание размытых requirements
• Декомпозиция больших User Stories
• Добавление acceptance criteria
• Переоценка (часто оценки меняются при понимании)

Практические советы Business Analyst

• Всегда пиши User Stories, а не задачи. "Добавить кнопку" → "Как пользователь, я хочу сбросить фильтры, чтобы вернуться к полному списку"
• Не смешивай фичи и баги. Иначе фичи всегда откладываются
• Регулярно чистить backlog. Раз в месяц просмотри все старые задачи
• Вовлекай разработчиков в grooming. Они выявят технические проблемы заранее
• Не расстраивайся по неделанным задачам. Backlog постоянно растёт — это нормально

Хороший Backlog — это кристальная ясность для команды о том, что нужно делать и в каком порядке.