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

Метрики для планирования спринта: от теории к практике

Как IT Project Manager с более чем 10-летним опытом, я рассматриваю метрики для планирования спринта не как абстрактные цифры, а как инструмент для прогнозирования, балансировки нагрузки и повышения предсказумости разработки. Моя цель — превратить исторические данные в обоснованные решения для команды. Я разделяю метрики на три ключевые категории: прогнозные, командные и качественные.

1. Прогнозные метрики (основа для оценки объёма работ)

Эти метрики помогают ответить на главный вопрос: «Сколько мы можем взять в спринт?».

• Скорость команды (Velocity) — среднее количество Story Points, завершённых командой за предыдущие спринты. Это основной ориентир.

  # Пример расчёта средней скорости за последние 3 спринта
  completed_points_last_sprints = [35, 40, 38]
  average_velocity = sum(completed_points_last_sprints) / len(completed_points_last_sprints)
  print(f"Средняя скорость команды: {average_velocity:.1f} story points")
  # Средняя скорость команды: 37.7 story points
  

    **Важно:** Использую не как жёсткий лимит, а как диапазон. Планирую на 80-90% от средней скорости, чтобы оставить буфер на непредвиденное.

• Прогноз завершения (Burndown Forecast) — на основе текущей скорости строю прогноз, успеем ли мы выполнить бэклог релиза (Release Burndown). Это помогает понять, нужно ли корректировать scope или сроки долгосрочных целей.

• Ёмкость команды (Capacity) — измеряется в человеко-часах или идеальных днях. Учитываю отпуска, больничные, обучение и другие факторы.

  Пример расчёта:
  Команда: 5 разработчиков
  Длительность спринта: 10 рабочих дней
  Идеальная ёмкость: 5 чел * 10 дней = 50 человеко-дней
  Корректировка (отпуск, митапы): -8 человеко-дней
  Фактическая ёмкость для планирования: 42 человеко-дня
  

2. Командные метрики (для балансировки и реалистичности)

Они обеспечивают здоровый темп работы и учитывают внутренние процессы.

• Коэффициент готовности (Readiness Factor) — какой процент задач в бэклоге спринта имеет чёткие критерии приёмки (DoR — Definition of Ready), дизайн и проработанную аналитику. Стремлюсь к >85% перед стартом планирования.
• Распределение типов работ — слежу за балансом между:

    *   Новой функциональностью (features)
    *   Техническим долгом (tech debt)
    *   Багфиксами (bugs)
    *   Операционной нагрузкой (оперативный support, дежурства)
    В идеале на новую функциональность выделяется 60-70% ёмкости спринта.

• Work In Progress (WIP) лимиты — контролирую количество одновременно выполняемых задач. Это снижает контекстное переключение и ускоряет поток завершения работ.

3. Качественные метрики (чтобы не жертвовать устойчивостью)

Без этих метрик скорость становится токсичной.

• Уровень дефектов (Defect Rate) — количество багов, обнаруженных после сдачи задачи в тестирование или в production. Рост этого показателя — сигнал к пересмотру Definition of Done или выделению времени на качество.
• Процент выполнения Definition of Done (DoD) — сколько задач полностью соответствуют всем критериям завершённости (протестированы, задокументированы, соответствуют стандартам кода).
• Индекс удовлетворённости команды (Team Happiness Index) — регулярный опрос (например, раз в спринт) по шкале от 1 до 5. Низкий показатель — прямой риск для скорости и качества в будущем.

Практический процесс планирования с использованием метрик

1. Подготовка: Анализирую скорость за последние 3-4 спринта и рассчитываю фактическую ёмкость команды на предстоящий спринт.
2. Приоритизация: Совместно с Product Owner отбираем задачи с наивысшим приоритетом и проверяем их готовность (Readiness Factor).
3. Оценка и баланс: Команда оценивает выбранные задачи. Сравниваю сумму story points с прогнозной скоростью. Добавляю или убираю задачи, чтобы попасть в целевой диапазон (например, 35±5 points). Проверяю распределение типов работ.
4. Фиксация и договорённости: Фиксируем цели спринта. Напоминаю команде о WIP-лимитах и важности соблюдения DoD.

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