Как будешь планировать спринт?

Планнирование спринта: практический подход с 10+ лет опыта

Планирование спринта — это ключевое событие в Scrum, которое задаёт тон всей итерации. Я подхожу к нему как к совместному процессу, где команда, Product Owner и я, как Scrum Master/Project Manager, формируем реалистичный и амбициозный план. Мой процесс состоит из нескольких четких этапов.

Этап 1: Подготовка и входные данные (Inputs)

Планирование не начинается с чистого листа. К моменту встречи у нас уже должны быть готовы критически важные артефакты:

• Готовый и приоритизированный Бэклог Продукта (Product Backlog): Product Owner обязан подготовить и актуализировать его до встречи.
• Результаты прошлого спринта: Анализ скорости команды (velocity), выполненные и невыполненные задачи, ключевые уроки из ретроспективы.
• Цель спринта (Sprint Goal): Product Owner формулирует общее направление — «чего мы хотим достичь за эти 2-4 недели?». Цель должна быть измеримой и ценной для бизнеса (например, «Реализовать функционал экспорта данных в CSV для отчёта Х»).
• Пропускная способность команды (Capacity): Учитываем отпуска, больничные, обучение и другие факторы, влияющие на доступное время.

Этап 2: Проведение сессии планирования (Two-part Event)

Саму сессию я провожу в два логических блока, как это рекомендует Scrum Guide.

Блок 1: «ЧТО мы будем делать?» (Определение содержания) Здесь фокус — на диалоге между Командой и Product Owner.

• Product Owner представляет верхние элементы бэклога, которые потенциально могут войти в спринт, и обсуждает с командой цель спринта.
• Команда задает уточняющие вопросы, проясняет требования и критерии приемки (DoD — Definition of Done).
• Совместно мы отбираем элементы бэклога, которые:

    1.  Наиболее соответствуют цели спринта.
    2.  Команда уверена, что может завершить с учетом своей пропускной способности.

• Результат блока — согласованный список элементов Бэклога Спринта (Sprint Backlog).

Блок 2: «КАК мы это сделаем?» (Разложение на задачи) Теперь команда переходит от пользовательских историй (User Stories) к техническим задачам.

• Каждую выбранную историю команда декомпозирует на конкретные задачи (tasks). Я помогаю фасилитировать этот процесс, но ответственность за декомпозицию лежит на команде.
• Для каждой задачи мы определяем:

    *   **Тип задачи**: Разработка, тестирование, дизайн, документация.
    *   **Оценку трудозатрат**. Я предпочитаю использовать **часы** для задач (не для историй!), так как это дает более точное понимание ежедневного прогресса. Оценки делает тот, кто будет выполнять задачу.

• Мы используем физическую или цифровую доску (Jira, Trello) для визуализации. Пример декомпозиции в Jira может выглядеть так:

Эпик: Улучшение отчетности
└── История: US-42 - Пользователь может экспортировать данные в CSV
    ├── Задача: DEV-101 - Реализовать endpoint для генерации CSV (8ч)
    ├── Задача: DEV-102 - Добавить кнопку "Экспорт" в UI (4ч)
    ├── Задача: QA-103 - Написать автотесты для endpoint (6ч)
    ├── Задача: QA-104 - Ручное тестирование сценария экспорта (3ч)
    └── Задача: DOC-105 - Обновить пользовательскую документацию (2ч)

Этап 3: Проверка реалистичности и фиксация плана

После создания задач мы суммируем оценки и сравниваем с доступной пропускной способностью команды.

• Если план перегружен (>120% capacity), мы возвращаемся к Product Owner, чтобы дескопировать (убрать часть scope) или переформулировать цель.
• Если план недогружен (<80%), можем взять дополнительную небольшую историю из бэклога.
• Важный принцип: План создает и обязуется выполнить команда, а не я. Моя роль — обеспечить процесс, устранить блокировки и помочь команде прийти к реалистичному обязательству.

Ключевые принципы и инструменты, которые я использую

• Time-boxing: Строго ограничиваю время встречи (макс. 2 часа на неделю спринта). Это дисциплинирует и повышает фокус.
• Визуализация: Всегда работаем с доской (Jira, Miro, физическая). «Увиденное — понятое».
• Definition of Ready (DoR): Мы не планируем истории, которые не соответствуют заранее согласованным критериям готовности (например, «есть дизайн-макет», «есть API-спецификация»).
• Учет рисков и зависимостей: Обсуждаем открытые вопросы и внешние зависимости явно. Если есть высокорисковая задача, мы можем запланировать её в начале спринта.
• Коммуникация: Я слежу, чтобы высказался каждый член команды, особенно тимлид, QA и дизайнер, для получения целостной картины.

Итогом планирования является четкий, прозрачный и разделяемый всеми план (Спринт Бэклог), измеримая цель спринта и команда, которая мотивированно берет на себя ответственность за результат. Этот план — не догма, а гипотеза, которую мы будем ежедневно проверять и корректировать на стендапах.