Как планировать спринт: полное практическое руководство для менеджера проекта

Планирование спринта (Sprint Planning) — это командная церемония, где определяется цель спринта (Sprint Goal), рассчитывается реальная емкость команды (Capacity) и отбираются задачи из бэклога. Успешное планирование требует предварительной подготовки (груминга), декомпозиции задач до 1–2 дней работы и учета рисков. Результат — согласованный Sprint Backlog и понимание, как команда достигнет цели.

1. Где мы находимся: цикл Scrum

Планирование спринта — лишь одна из церемоний. Его качество напрямую зависит от того, насколько хорошо команда подготовила бэклог на предыдущем этапе.

Product Backlog

↓

Backlog Refinement (Подготовка и оценка задач)

↓

Sprint Planning (Планирование: Цель + Емкость + Отбор)

↓

Sprint (Работа + Daily Scrum)

↓

Sprint Review (Демонстрация результата)

↓

Sprint Retrospective (Анализ процессов)

↓

Следующий Sprint Planning

2. Когда НЕ начинать Sprint Planning

Не тратьте время команды впустую. Отмените или перенесите встречу, если:

• ❌ Бэклог не приоритизирован (Product Owner не знает, что важно).
• ❌ Задачи не имеют описания и критериев приемки (нет Definition of Ready).
• ❌ Не сформулирована гипотеза Sprint Goal.
• ❌ Неизвестна реальная емкость команды (кто-то внезапно ушел в отпуск).
• ❌ На встрече отсутствует ключевой разработчик или тестировщик.

3. Подготовка: чек-лист PM перед встречей

Сохраните этот чек-лист. Если хотя бы один пункт не выполнен, планирование превратится в хаос.

• Все задачи в топ-10 бэклога имеют четкое описание.
• У задач прописаны критерии приемки (Acceptance Criteria).
• Крупные эпики декомпозированы на задачи ≤ 2 дней работы.
• Приоритет задач согласован с Product Owner.
• Известна номинальная и реальная емкость команды на спринт.
• Предварительно сформулирована гипотеза Sprint Goal.
• В бэклог заложен буфер на технический долг и поддержку.
• Команда знает и понимает Definition of Done (DoD).

4. Definition of Ready (DoR) vs Definition of Done (DoD)

Частая ошибка — путать готовность задачи к взятию в работу и готовность к сдаче.

5. Пошаговый алгоритм планирования

Шаг 1: Расчет емкости команды (Capacity Planning)

Нельзя просто умножить количество людей на 8 часов. Используйте реальные цифры.

Пример расчета емкости на 2-недельный спринт (10 рабочих дней):

Именно 253 часа, а не 400, вы можете заполнить задачами.

Шаг 2: Формулировка Sprint Goal

Цель спринта — это не список задач, а бизнес-результат. Используйте шаблон:

Шаблон Sprint Goal:

«После окончания спринта пользователь сможет [действие/ценность] благодаря реализации [ключевые фичи]».

Плохо: «Закрыть 15 задач по авторизации».

Хорошо: «Пользователь сможет зарегистрироваться и войти в аккаунт через Google OAuth, чтобы начать тестирование основного функционала».

Шаг 3: Отбор и декомпозиция задач (Decision Tree)

Команда «вытягивает» задачи из топ-10 бэклога, пока не заполнит реальную емкость (253 часа). Используйте это правило для каждой задачи.

Какие задачи НЕЛЬЗЯ брать в спринт:

• ❌ «Сделать сайт» (слишком крупно).
• ❌ «Оптимизировать базу данных» (нет критерия успеха).
• ❌ «Разобраться с багом» (это задача-исследование, см. ниже про Spikes).

Какие задачи БРАТЬ можно:

• ✔ «Настроить форму регистрации с валидацией email».
• ✔ «Реализовать кнопку входа через [название метода]».
• ✔ «Добавить фильтр товаров по цене на фронтенде».

6. Реальный пример планирования

Контекст: Команда делает интернет-магазин. Длительность спринта: 2 недели. Реальная емкость: 253 часа.

Исходный приоритизированный бэклог:

1. Регистрация (20 ч)
2. Авторизация (30 ч)
3. Корзина товаров (80 ч)
4. Оформление заказа (120 ч)
5. Отправка Email-подтверждений (40 ч)
6. Оплата картой (90 ч)
7. Отзывы о товарах (50 ч)

Процесс отбора:

Команда начинает брать задачи сверху. Регистрация (20) + Авторизация (30) + Корзина (80) + Оформление заказа (120) = 250 часов.

Емкость (253 ч) исчерпана.

Итог Sprint Backlog: Регистрация, Авторизация, Корзина, Оформление заказа.

Sprint Goal: Пользователь может собрать корзину и оформить первый заказ.

Задачи «Оплата», «Email» и «Отзывы» остаются в бэклоге и ждут следующего спринта.

7. Управление рисками на планировании

Не игнорируйте неизвестное. Заполните простую матрицу рисков прямо на встрече:

8. Плохое vs Хорошее планирование (Антипример)

9. Ключевые метрики: Velocity и Burndown Chart

Что такое Velocity и как его считать

Velocity (Скорость команды) — это среднее количество Story Points (или часов), которое команда фактически закрывает за спринт.

• Как считать: Сложите оценку всех задач, перешедших в статус «Done» в прошлых 3 спринтах, и разделите на 3.
• Главное правило: Velocity разных команд нельзя сравнивать. Это внутренний ориентир команды для планирования, а не KPI для давления. Искусственное завышение Velocity ведет к выгоранию и техническому долгу.

Как читать Burndown Chart (Диаграмма сгорания)

Это график, показывающий, сколько работы осталось сделать до конца спринта.

• Плато (горизонтальная линия): Задачи не двигаются. Причина: блокеры, недооценка сложности или отсутствие DoR.
• Резкое падение в конце: Команда не вела задачи в трекере ежедневно или задачи были слишком крупными. Решение: декомпозиция и ежедневное обновление статусов. Для удобного отслеживания таких метрик команда может использовать Интабия Платформа, где отчеты по трудозатратам и статусам строятся автоматически.

10. Что делать ПОСЛЕ Sprint Planning

Планирование не заканчивается фразой «всем спасибо». PM должен сделать следующее:

1. Проверить, что Sprint Goal записан и виден всей команде.
2. Убедиться, что у каждой задачи в спринте есть ответственный (Assignee).
3. Обновить доску (перевести задачи в колонку «Sprint Backlog» или «To Do»).
4. Уведомить стейкхолдеров о том, что именно будет сделано к концу спринта.
5. Провести первый Daily Scrum на следующее утро, чтобы подтвердить старт работ.

Как понять, что планирование прошло хорошо?

Уходите со встречи, только если вся команда может ответить на 6 вопросов: Зачем мы это делаем? Что входит в спринт? Что НЕ входит? Кто и чем может помочь? Какие есть риски? Сколько часов у нас осталось в запасе?

11. Как помогает AI в планировании

ИИ не принимает решения за команду, но экономит часы рутины. Например, ИИ-ассистент Юля может:

• Сделать саммари встречи, чтобы PM не перечитывал часовой чат.
• Подготовить черновик протокола.

12. FAQ: Ответы на частые SEO-запросы

В чем разница между Sprint Planning и Backlog Refinement?

Refinement (груминг) — это подготовка задач (описание, оценка, декомпозиция) в текущем спринте для будущих. Planning — это финальный отбор и фиксация обязательств на ближайший спринт.

Можно ли менять Sprint Backlog после начала спринта?

Да, но только по инициативе команды и с согласия Product Owner. Если всплывает критичный баг, команда имеет право убрать из спринта низкоприоритетную задачу, чтобы сохранить Sprint Goal.

Что такое Spike-задачи?

Это задача-исследование. Если команда не может оценить задачу («Разобраться с багом»), она берет Spike с фиксированным таймбоксом (например, 4 часа), чтобы изучить проблему и вернуть задачу в бэклог уже с оценкой и планом.

В чем разница планирования в Scrum и Kanban?

В Scrum планирование жесткое: фиксируется объем на 2 недели. В Kanban планирование непрерывное: задачи берутся из бэклога по мере освобождения слотов (pull-система), исходя из WIP-лимитов, без фиксированных итераций.

Что делать, если Sprint сорван (команда ничего не успела)?

Не ищите виноватых. На Retrospective честно разберите причины: переоценка емкости? Плохой DoR? Внешние блокеры? Скорректируйте процесс и снизьте планируемый Velocity на следующий спринт.

Приложение: Шаблон Sprint Planning

Используйте эту структуру для ведения встречи или создания документа в вашей системе управления проектами.

Итог: Планирование спринта — это не бюрократия, а инструмент защиты команды от хаоса. Четкая цель, честный расчет емкости и готовность сказать «нет» лишним задачам превращают спринт из гонки на выживание в предсказуемый процесс создания ценности.