Метрики команды: velocity, lead time

Метрики команды — измеримые показатели производительности и здоровья Agile-команды, позволяющие делать обоснованные решения о планировании и улучшении процессов.

Зачем нужно

Без метрик управление командой — гадание. Velocity показывает, сколько работы команда реально выполняет за спринт, а не сколько обещает. Lead Time показывает, сколько идёт задача от создания до завершения. Понимание этих метрик помогает реалистично планировать и выявлять узкие места.

Где используется

  • Scrum Planning — velocity для прогнозирования спринта
  • Управление бэклогом — lead time для расстановки приоритетов
  • Ретроспектива — тренды за несколько спринтов
  • Отчёты для стейкхолдеров — объективная картина прогресса

Ключевые метрики

Velocity (Скорость команды)

Velocity = сумма Story Points завершённых задач за спринт

Пример 5 спринтов:
  Sprint 1: 22 SP
  Sprint 2: 28 SP
  Sprint 3: 25 SP
  Sprint 4: 27 SP
  Sprint 5: 26 SP
  Средняя velocity: 25.6 SP

Использование:
  Следующий спринт планируем ~25 SP
  (не больше средней, лучше чуть меньше)

ВАЖНО: velocity — инструмент планирования,
       НЕ показатель эффективности отдельных людей

Lead Time (Время выполнения)

Lead Time = время от создания задачи до её завершения

Создана: 1 апреля
Взята в работу: 5 апреля (4 дня в бэклоге)
Завершена: 8 апреля (3 дня в работе)
Lead Time = 7 дней
Cycle Time = 3 дня (только время активной работы)

Хорошая метрика для:
- Оценки предсказуемости команды
- Нахождения задач, зависших в бэклоге
- SLA обязательств перед бизнесом

Cycle Time

Cycle Time = время от начала работы до завершения
             (без ожидания в бэклоге)

Если Cycle Time > 5 дней для большинства задач →
задачи слишком большие, нужна декомпозиция

DORA Metrics (DevOps Research and Assessment)

4 метрики высокопроизводительных команд:

1. Deployment Frequency
   (как часто деплоим)
   Elite: несколько раз в день
   Low: раз в месяц или реже

2. Lead Time for Changes
   (от коммита до продакшена)
   Elite: менее 1 часа
   Low: от 6 месяцев

3. Change Failure Rate
   (% деплоев, приводящих к инциденту)
   Elite: 0–15%
   Low: 46–60%

4. Time to Restore Service
   (время восстановления после инцидента)
   Elite: менее 1 часа
   Low: от 1 недели

Чего не измерять

Количество строк кода:
  Больше строк ≠ лучше работа

Velocity отдельного разработчика:
  Velocity — командная метрика
  Индивидуальная "velocity" ломает кооперацию

Количество закрытых задач без учёта SP:
  10 задач по 1 SP ≠ 2 задачи по 8 SP

Частые ошибки

Ошибка Проблема Решение
Сравнивать velocity разных команд Разные SP-шкалы, разные типы работы Velocity только для собственного трекинга
Давить на команду ради velocity Технический долг, моральный ущерб Velocity — прогноз, не KPI
Трекать только velocity, игнорировать quality Быстро, но неправильно Добавить качественные метрики (bugs/sprint)
Использовать Lead Time без декомпозиции Высокий Lead Time скрывает проблемы Смотреть распределение, не только среднее

Связанные темы

Ресурсы