Как понять что команда может сделать за спринт?

Оценка возможностей команды в спринте: многоуровневый подход

Оценка потенциала команды (capacity) на спринт — это краеугольный камень эффективного планирования в Agile/Scrum. Это не просто гадание, а комбинация данных, эмпирического опыта и постоянной адаптации. Вот ключевые методы, которые я применяю на практике.

1. Основной метод: Расчёт фактического потенциала (Capacity Planning)

Это количественная оценка. Сначала вычисляем доступные часы всех разработчиков в спринте, вычитая отпуска, больничные, обучение, корпоративные мероприятия и прочие "затравочные" активности (overhead). Затем переводим это в идеальные инженерные часы (ideal hours) или, что чаще, в стори поинты (story points) на основе исторических данных.

Пример расчёта в условных часах (для упрощения):

Команда из 5 разработчиков.
Длина спринта = 10 рабочих дней.
Идеальный рабочий день на задачи спринта = 6 часов (остальное — митинги, почта, помощь коллегам).

Общий потенциал в часах = 5 чел × 10 дней × 6 час = 300 идеальных часов.
Учитываем плановые отсутствия: -40 часов.
Финальный потенциал команды на спринт = 260 часов.

На основе прошлых спринтов мы знаем, что в среднем 1 story point ≈ 4 часа работы для этой команды. Таким образом, прогноз на спринт ≈ 260 / 4 = 65 story points.

2. Анализ исторической скорости (Velocity)

Velocity — это самый объективный индикатор. Это количество стори поинтов, которое команда реально завершает в конце каждого спринта, взятое в среднем за последние 3-6 спринтов.

Спринт 1: Запланировано 50 sp, завершено 45 sp.
Спринт 2: Запланировано 48 sp, завершено 50 sp.
Спринт 3: Запланировано 55 sp, завершено 47 sp.
Средняя скорость (velocity) = (45 + 50 + 47) / 3 ≈ 47 sp.

Золотое правило: Для планирования следующего спринта я беру 80-90% от средней скорости, чтобы создать буфер на непредвиденные сложности и учесть закон Хофштадтера ("Работа всегда занимает больше времени, чем вы ожидаете, даже если учесть закон Хофштадтера"). Таким образом, для среднего показателя в 47 sp, рекомендуемый объём — 38-42 sp.

3. Качественные факторы в планировании

Цифры — это основа, но без контекста они лгут. На планировании спринта (Sprint Planning) мы учитываем:

• Технический долг: Запланирован ли в спринт рефакторинг или исправление багов?
• Сложность и неизвестность (uncertainty) задач: Есть ли задачи с высокими рисками или исследования (spikes)? Для них закладываем дополнительный буфер.
• Зависимости (dependencies): Ждём ли мы ответа от другой команды или внешнего API?
• Состояние команды: Есть ли болезнь, адаптация новичка, смена фреймворка?
• Нетехнические работы: Участие в найме, менторинг, подготовка демо.

Ключевые принципы и красные флаги

• Команда оценивает, Product Manager/Product Owner приоритизирует. Я, как Project Manager / Scrum Master, фасилитирую этот процесс, но финальное решение о том, сколько они могут взять, всегда остаётся за командой.
• Стабильная скорость — залог точного прогноза. Сильные колебания velocity сигнализируют о проблемах: нестабильные требования, технические проблемы, неверная оценка.
• Проблема "перенесённых задач" (spill-over). Если команда регулярно не завершает запланированное, это главный сигнал, что мы перегружаем спринт. Нужно снижать объём планирования.
• Учёт праздников и "затравочных" часов. Летом или перед Новым годом capacity может быть на 30-40% ниже — это необходимо честно закладывать в расчёты.

Итог: Чтобы понять, что команда может сделать за спринт, я создаю прогноз, основанный на данных (историческая скорость, расчёт capacity), и затем корректирую его на планировании, учитывая все качественные факторы и мнение самой команды. Это постоянный итеративный процесс, цель которого — не "запихнуть" максимум задач, а сформировать реалистичное и достижимое обязательство (commitment), которое сохраняет устойчивый темп и качество работы в долгосрочной перспективе.