Как посчитать velocity?

Расчёт Velocity в Agile проектах

Velocity — ключевой метрик в Scrum/Agile, который я использую более 10 лет для планирования и прогнозирования. Расскажу о практическом применении.

Что такое Velocity

Velocity — это количество story points (единиц работы), которое команда успевает закончить за один спринт.

Если команда закончила 35 story points за спринт, то velocity = 35.

Шаги расчёта Velocity

Шаг 1: Оценить задачи в story points

На планировании спринта команда оценивает каждую задачу. Я использую Fibonacci последовательность:

• 1 point — очень простая (1-2 часа)
• 2-3 points — простая (половина дня работы)
• 5 points — средняя (1-2 дня)
• 8 points — сложная (3-5 дней)
• 13 points — очень сложная (более недели)

Важно: оценка отражает не время, а сложность и неопределённость.

Шаг 2: В конце спринта подсчитать закончившиеся задачи

Критерий "закончено": ✓ Код написан и залит в main ✓ Code review одобрен ✓ Автотесты написаны и проходят ✓ QA тестировал и одобрил ✓ Задача в статусе "Done"

НЕ считаем "почти готовые" или "в процессе" задачи.

Шаг 3: Рассчитать среднее за несколько спринтов

Одного спринта недостаточно. Считаю среднее за 3-5 последних спринтов:

Пример:

• Спринт 1: 32 points
• Спринт 2: 36 points
• Спринт 3: 34 points
• Спринт 4: 38 points
• Спринт 5: 35 points

Среднее = (32 + 36 + 34 + 38 + 35) / 5 = 35 points

Как я применяю Velocity

1. Планирование следующего спринта

Если среднее velocity = 35, то я планирую в следующий спринт примерно 35 points работы.

• Меньше 35 → команда недозагружена
• Больше 35 → переработка и выгорание

2. Прогнозирование сроков релиза

Если в бэклоге 150 points новых фич, а velocity = 35:

Время = 150 / 35 = 4.3 спринта = примерно 8-9 недель

Можно обещать заказчику: "Реализуем это за 2 месяца".

3. Планирование дорожной карты

Руководству показываю: "У нас 500 points в бэклоге. При velocity 35 это занимает 15 спринтов, примерно 7-8 месяцев работы".

4. Выявление проблем

Резкое падение velocity — сигнал бедствия:

• Спринты 1-4: velocity 35-38
• Спринты 5-6: velocity 20

Я спрашиваю:

• Команда выгорела?
• Появились много багов для срочного исправления?
• Задачи оценены неправильно?
• Есть ли проблемы с инструментами или процессами?

Примеры из практики

Пример 1: Стабильная команда

Одна команда 10 спринтов подряд выполняла 40-45 points. Это позволило:

• Точно планировать релизы (±2%)
• Обещать заказчику сроки с 95% уверенностью
• Видеть проблемы за 1-2 спринта до срыва

Пример 2: Нестабильная команда

Другая: velocity 25, 50, 30, 45, 35, 28...

Корневые причины:

• Неправильная калибровка оценок (разработчики по-разному понимают "5 points")
• Много срочных опер. работ
• Внешние зависимости

Что я сделал:

• Planning Poker сессия для выравнивания
• Выделили отдельный спринт для опер. работ
• Добавили резерв на непредвиденное (20% буфер)

Результат: velocity стабилизировалась на 35-40.

Пример 3: Рост новой команды

• Месяц 1: velocity 15 (команда разбирается в процессе)
• Месяц 2: velocity 22 (начинают работать быстрее)
• Месяц 3: velocity 30
• Месяц 4+: velocity 35 (стабилизируется)

Это нормально и ожидаемо.

Важные нюансы

Не сравнивай velocity разных команд Одна команда: 40 points. Другая: 20 points. Это не значит первая лучше. Просто их оценки откалиброваны по-разному.

Учитывай отпуска и больничные Если в спринте 2 разработчика в отпуске, velocity упадёт на 30-40%. Это предсказуемо.

Velocity может расти при улучшении процессов

• Внедрил лучшую архитектуру → velocity растёт
• Улучшил тесты → меньше багов → velocity растёт
• Автоматизировал деплой → экономим время → velocity растёт

Это хороший знак.

Используй для планирования, не для оценки людей Ловушка: "Твоя velocity упала, ты плохо работаешь". Это неправильно. Velocity — метрика команды, не индивида. Если падает, надо найти системные проблемы.

Итого

Velocity помогает:

• Планировать реалистично
• Прогнозировать сроки
• Выявлять проблемы
• Управлять ожиданиями заказчика
• Видеть эффект от улучшений процессов

Это простой, но мощный инструмент управления.