Приоритизация, уточнение, поддержка, картографирование историй
Время освоения: ~40 минут
| Бэклог | Содержание | Владелец | Горизонт |
|---|---|---|---|
| Product Backlog | Все требования: истории, баги, техдолг | Product Owner | Весь продукт |
| Sprint Backlog | Задачи текущего спринта + план | Команда | 1–4 недели |
| Release Backlog | Задачи конкретного релиза | PO + Команда | 2–4 спринта |
| Параметр | Значение |
|---|---|
| Частота | 1–2 раза в неделю |
| Длительность | 1–2 часа на сессию |
| Максимум времени | ≤ 10% от времени команды |
| Результат | Верхние 2–3 спринта бэклога "готовы" |
| Метод | Принцип | Когда использовать |
|---|---|---|
| MoSCoW | Must / Should / Could / Won't | Первоначальная расстановка приоритетов |
| Value vs Effort | Матрица 2×2 | Визуальная приоритизация |
| WSJF | Ценность ÷ Время выполнения | Сложные решения, много задач |
| Kano Model | Basic / Performance / Delighters | Продуктовая стратегия |
WSJF = Бизнес-ценность ÷ Размер (story points)
Чем выше WSJF → тем выше приоритет
| Признак | Проверка |
|---|---|
| Приоритизирован | Верхние задачи — самые ценные |
| Актуален | Нет задач старше 3 месяцев без пересмотра |
| Готов к спринту | Верхние истории соответствуют INVEST |
| Прозрачен | Команда знает приоритеты и причины |
Бэклог — это упорядоченный список всех требований к продукту, которые команда должна реализовать. Это "список дел" для всей команды, но не просто список задач — это живой артефакт, который постоянно эволюционирует.
💡 Ключевая мысль: Бэклог — это не документ, а инструмент принятия решений. Его ценность измеряется не количеством записей, а качеством принимаемых решений.
⚠️ Частая ошибка: PO пытается управлять бэклогом в одиночку без участия команды. Это приводит к нереалистичным планам и низкому качеству.
Регулярная работа над бэклогом для обеспечения его готовности:
Хорошая пользовательская история должна быть:
Story Mapping — это техника визуального представления пользовательских историй по потокам работы пользователя (user journey). Создается горизонтально (основные потоки) и вертикально (детализация).
[Регистрация] → [Поиск товаров] → [Выбор товара] → [Корзина] → [Оплата] → [Доставка]
| | | | | |
| | | | | |
[Вход] [Фильтры] [Сравнение] [Скидки] [Карты] [Отслеживание]
[Регистрация] [Категории] [Избранное] [Подарки] [PayPal] [SMS-уведомления]
💡 Ключевая мысль: Story Mapping помогает перейти от списка задач к пониманию пользовательского опыта и ценности для бизнеса.
Плохо:
"Сделать авторизацию"
→ Неясно, что именно, какие функции, какая безопасность
Хорошо:
"Как пользователь, я хочу войти в систему с помощью email и пароля, чтобы получить доступ к своим данным"
Критерии приемки:
| Задача | Ценность (1-10) | Усилия (story points) | WSJF |
|---|---|---|---|
| Регистрация | 9 | 8 | 1.13 |
| Авторизация | 8 | 5 | 1.6 |
| Профиль пользователя | 7 | 13 | 0.54 |
| Поиск по каталогу | 6 | 10 | 0.6 |
Результат: Сначала делаем авторизацию (WSJF = 1.6), потом регистрацию (1.13)
Проблема: Бэклог не обновлялся 3 месяца, новые требования добавляются в отдельный документ.
Решение:
Что это: Когда разработчики или другие члены команды добавляют задачи в бэклог без согласования с Product Owner (PO) и его приоритетами.
Проблемы:
Как избежать:
⚠️ Важно: Product Owner единственный отвечает за содержимое и приоритеты Product Backlog. Другие роли могут давать обратную связь, но окончательное решение за PO.
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Refinement не проводится | Sprint Planning превращается в хаос, задачи без AC и оценки | Refinement 1–2 раза в неделю, 1–2 часа, ≤10% времени команды |
| PO управляет бэклогом в одиночку | Нереалистичные планы, команда не понимает задачи, много блокировок | Refinement проводится вместе с Dev Team: они дают оценку и выявляют риски |
| Бэклог не чистится, накапливается хлам | Сотни устаревших задач, сложно приоритизировать, доверие к бэклогу падает | Ежеквартально проводить «бэклог-ревизию»: удалять то, что неактуально |
| Приоритеты не объясняются команде | Команда делает «что сказали», не понимает зачем, теряет мотивацию | PO объясняет «почему это важно сейчас» для каждого спринта |
| У историй нет Acceptance Criteria | Команда трактует «готово» по-разному, PO часто переделывает | AC — обязательное условие Definition of Ready для любой истории |
| Технический долг не попадает в бэклог | Долг накапливается, скорость разработки со временем падает | Техдолг = такие же истории в Product Backlog с явным приоритетом |
Преобразуйте плохую историю в хорошую по INVEST-критериям:
Исходная: "Сделать корзину покупок"
Ваша задача: Перепишите историю и добавьте 3-4 критерия приемки.
У вас есть 4 задачи. Распределите их по приоритетам (1-4) используя MoSCoW:
Обоснуйте свой выбор.
Вы — Product Owner. Вам нужно подготовить 3 верхних элемента бэклога к следующему спринту. Что вы сделаете на refinement-сессии?
Список задач:
🎯 Главный вывод: Управление бэклогом — это не административная задача, а стратегический процесс, который определяет успех продукта. Инвестируйте время в него, и вы получите прозрачность, предсказуемость и высокую ценность доставляемых результатов.
Далее: Agile Anti-patterns