Story points, оценка, планирование мощности, обязательства
Время освоения: ~40 минут
| Уровень | Частота | Горизонт | Инструменты |
|---|---|---|---|
| Product Planning | Раз в квартал | 3–12 месяцев | Roadmap, OKR, Epic Backlog |
| Release Planning | Перед релизом (2–4 спринта) | 1–3 месяца | Velocity, приоритизация эпиков |
| Sprint Planning | Каждый спринт | 1–4 недели | Sprint Goal, capacity, Story Points |
| Шаг | Действие | Кто |
|---|---|---|
| 1 | Обзор Sprint Goal — бизнес-ценность | PO объясняет |
| 2 | Выбор задач из Product Backlog | PO + Команда |
| 3 | Проверка: укладывается ли в capacity? | Команда |
| 4 | Детальное планирование, разбивка на подзадачи | Команда |
| 5 | Финальная формулировка Sprint Goal | Совместно |
Capacity = (Кол-во людей × Дней × Часов/день) − непроизводственные часы
Непроизводственные: церемонии + встречи + обучение + отпуска
| Ошибка | Последствие |
|---|---|
| Нет Sprint Goal | Команда теряет фокус |
| Планирование без refinement | Блокировки во время спринта |
| Игнорирование capacity | Выгорание, срыв спринта |
| Жёсткий commitment | Команда жертвует качеством |
Планирование в Agile — это непрерывный процесс адаптации, а не одноразовое создание детального плана на весь проект.
💡 Ключевая мысль: В Agile мы планируем не то, что будет сделано, а как будем принимать решения о том, что делать дальше.
Цель: Определить стратегию продукта и долгосрочную видение Частота: Раз в квартал или при значительных изменениях Инструменты:
Пример roadmap:
Q1 2024: MVP с базовыми функциями
Q2 2024: Интеграции с ключевыми системами
Q3 2024: Расширение функционала для enterprise-клиентов
Q4 2024: Масштабирование и оптимизация производительности
Цель: Определить, какие функции будут включены в конкретный релиз Частота: Перед началом каждого релиза (обычно 2-4 спринта) Процесс:
Формула: Количество спринтов = Общий объем / Velocity
Цель: Выбрать задачи для текущего спринта и спланировать их выполнение Частота: Перед каждым спринтом (time-boxed до 8 часов для 2-недельного спринта) Две части:
⚠️ Важно: Sprint Planning — это не распределение задач, а совместное принятие решений о том, что можно достичь за спринт.
Подготовка:
Сама сессия:
Правила:
Цель: Сделать верхние элементы Product Backlog "спринт-готовыми" Частота: 1-2 раза в неделю (не во время спринта!) Процесс:
Время: 1-2 часа на сессию, не более 10% времени команды
Цель: Учесть реальную доступность команды Факторы:
Формула: Доступная мощность = (Количество дней × Часов в день) - Непроизводственные часы
Пример:
Ситуация: Команда берет 160 story points, но выполняет только 120.
Анализ:
Решение:
Ситуация: PO говорит: "Эти 5 задач должны быть в спринте, потому что они важны для руководства".
Подход:
| Ошибка | Последствия | Как избежать |
|---|---|---|
| Планирование на год вперед | План устаревает, команда теряет гибкость | Использовать roadmap с высоким уровнем абстракции |
| Нет Sprint Goal | Команда теряет фокус, результаты размыты | Всегда формулировать одну четкую цель спринта |
| Оценка без refinement | Некачественные задачи, постоянные блокировки | Регулярный refinement перед планированием |
| Игнорирование capacity | Перегрузка команды, выгорание, снижение качества | Учитывать все непроизводственные часы |
Что это: Когда команда обязуется выполнить все задачи спринта независимо от изменений в контексте (новые требования, блокеры, болезни).
Проблемы:
Как избежать:
Что это: Когда планирование превращается в показательное мероприятие для руководства без реальной пользы и улучшения процессов.
Примеры:
Результат: Потеря ценности планирования, неточное планирование, снижение мотивации команды.
Как избежать:
Что это: Когда планирование становится препятствием для работы вместо помощи в организации процесса, отнимая время без реальной пользы.
Примеры:
Решение:
⚠️ Важно: Sprint Commitment — это договоренность, а не жесткий контракт. Цель — создать ответственность и фокус, а не давление на команду.
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Sprint Planning без Sprint Goal | Команда выполняет задачи, а не достигает цели; при изменениях нет ориентира | Сформулировать одну чёткую бизнес-цель до выбора задач |
| Нет Backlog Refinement перед Planning | Planning превращается в мозговой штурм, задачи плохо понятны | Refinement 1–2 раза в неделю, верхние 2–3 спринта всегда «готовы» |
| Capacity не учитывается | Систематический срыв спринтов, выгорание команды | Считать реальную мощность: (дни × часы) − отпуска − встречи − обучение |
| PO навязывает конкретные задачи без обсуждения | Команда не владеет commitment, теряет ответственность | PO предлагает приоритеты и Sprint Goal, команда сама решает объём |
| Планирование детального roadmap на год вперёд | Plan устаревает сразу, гибкость потеряна | Детально — ближайший спринт, грубо — квартал, направление — год |
| Не используют историю velocity при планировании | Хронически перегруженные спринты, срыв дедлайнов | Velocity последних 3–5 спринтов — ориентир, не жёсткий лимит |
У вас есть задачи для спринта:
Задача: Сформулируйте один четкий Sprint Goal, который объединяет эти задачи.
Команда: 6 человек Спринт: 2 недели (10 рабочих дней) Часы в день: 6 часов Непроизводственные часы:
Задача: Рассчитайте доступную мощность команды в story points, если средний velocity = 40 points/спринт.
🎯 Главный вывод: Успешное планирование в Agile — это не создание идеального плана, а развитие способности команды принимать обоснованные решения в условиях неопределенности. План — это не цель, а средство для достижения цели.
Далее: Церемонии