Backlog Refinement Guide

Фреймворк DEEP для бэклога

• Detailed Appropriately: Ближайшие элементы детализированы, долгосрочные — на высоком уровне
• Emergent: Постоянно эволюционирует на основе обучения
• Estimated: Относительное размерование с помощью story points
• Prioritized: Четкая сортировка на основе ценности и рисков

Definition of Ready

• Четко определены критерии принятия
• Зависимости выявлены и разрешены
• Оценены командой разработки
• Достаточно малы для завершения за спринт
• Тестируемы и демонстрируемы
• Соответствуют Definition of Done

Шаблон пользовательской истории

Как [персона/роль]
Я хочу [возможность/функциональность]
Чтобы [бизнес-ценность/результат]

Критерии принятия:
- Дано [контекст]
  Когда [действие]
  Тогда [результат]

Definition of Done:
- [ ] Код отревьюван и одобрен
- [ ] Юнит-тесты написаны и проходят
- [ ] Интеграционные тесты проходят
- [ ] Документация обновлена

Техники разбиения историй

Оригинал: "Как пользователь, я хочу купить продукт"
Разбиение на:
- "Как пользователь, я хочу добавить товары в корзину"
- "Как пользователь, я хочу ввести платежную информацию"
- "Как пользователь, я хочу подтвердить заказ"

Структура сессии рефайнмента

Подготовка (Product Owner)

1. Просмотреть и приоритизировать элементы бэклога
2. Собрать контекст, wireframes, требования
3. Подготовить вопросы для обсуждения
4. Установить цели сессии

Повестка дня (90 минут)

0-10 мин:  Просмотр Definition of Ready
10-70 мин: Обзор историй (8-10 историй)
           - Представление контекста (5 мин)
           - Уточнение требований (10 мин)
           - Выявление зависимостей (5 мин)
           - Оценка (5 мин)
70-85 мин: Обсуждение приоритизации
85-90 мин: Планы действий

Калибровка Story Points

1 балл:  Простое изменение конфигурации
2 балла: Небольшое добавление функции, простой баг
3 балла: Средняя функция с четкими требованиями
5 баллов: Сложная функция, требующая исследования
8 баллов: Большая функция, несколько компонентов
13+ баллов: Epic, требующий декомпозиции

Planning Poker

1. Product Owner представляет историю
2. Команда задает уточняющие вопросы
3. Каждый выбирает оценку приватно
4. Показать оценки одновременно
5. Обсудить различия (фокус на крайних)
6. Переоценить до консенсуса

Шаблон истории технического долга

Как [команда разработки]
Мне нужно [техническое улучшение]
Чтобы [влияние на поддерживаемость/производительность]

Технический контекст:
- Текущее состояние: [описание]
- Предлагаемое решение: [подход]
- Риск если не решить: [последствия]

Критерии принятия:
- [Измеримые технические результаты]

Нефункциональные требования

• Производительность: "Страница загружается за 2 секунды на 3G"
• Безопасность: "Все входные данные валидированы"
• Доступность: "Навигация с клавиатуры для всех функций"
• Юзабилити: "Онбординг менее чем за 5 минут"

Метрики здоровья бэклога

• Эффективность рефайнмента: Истории без возврата в бэклог
• Точность оценки: Расхождение фактических и оценочных усилий
• Пропускная способность: Story points за спринт
• Время выполнения: От создания до завершения
• Частота дефектов: Багов на story point

Композиция бэклога

Спринт N:     100% готовых историй
Спринт N+1:   80% готовых историй
Спринт N+2:   60% готовых историй
Следующие 2-4: Высокоуровневые функции
Позже:        Epic'и и темы

Анти-паттерны и решения

"Всё высокого приоритета"

"Массивная история"

"Детали реализации"

"Молчаливый стейкхолдер"

Инструменты удаленного рефайнмента

• Коллаборация: Miro, Mural
• Оценка: Planning Poker Online
• Документация: Confluence, Notion

Вопросы ретроспективы

1. Какие истории вызвали путаницу?
2. Какой информации не хватало?
3. Насколько точны были оценки?
4. Какие зависимости мы упустили?
5. Как улучшить Definition of Ready?