Velocity в Scrum: как измерять скорость команды и прогнозировать сроки

Команда взяла в спринт 40 сторипоинтов, закрыла 32. В следующий раз запланировала 45 — закрыла 28. Менеджер нервничает, разработчики не понимают причин срывов, заказчик теряет доверие. Знакомая картина?

Проблема в том, что команда не отслеживает свою реальную скорость работы. А когда нет понимания производительности, планирование превращается в гадание на кофейной гуще. Velocity решает эту проблему — показывает, сколько работы команда действительно способна выполнить за спринт.

Без этой метрики невозможно адекватно планировать релизы, прогнозировать сроки и управлять ожиданиями стейкхолдеров. Разберемся, как правильно измерять и применять velocity, чтобы проекты перестали срываться.

Что такое velocity в Scrum

Velocity — это количество работы, которое команда выполняет за один спринт. Измеряется в тех же единицах, в которых оценивают задачи: сторипоинтах, идеальных часах или других условных единицах оценки.

Метрика показывает фактическую производительность. Не планы, не обещания — реальный объем завершенной работы. Именно завершенной: если задачу не закрыли полностью, она не входит в velocity спринта.

Метрика работает на уровне команды, а не отдельных разработчиков. Это принципиально важно. Цель Scrum — командная эффективность, а не соревнование между участниками. Когда начинают сравнивать velocity отдельных людей, система ломается.

Показатель скорости становится полезным инструментом после 3-5 спринтов. За это время вырисовывается средняя производительность команды. Один спринт ничего не значит — могут быть отпуска, болезни, форс-мажоры.

Как рассчитывается velocity

Расчет предельно прост. В конце спринта суммируете сторипоинты всех полностью завершенных задач. Получаете velocity спринта.

Базовая формула

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

Допустим, команда закрыла такие задачи:

Velocity спринта: 8 + 5 + 13 + 3 = 29 сторипоинтов.

Задачу на 21 SP начали, но не завершили? Она не входит в velocity. Частичное выполнение не считается — это фундаментальное правило метрики.

Средний velocity команды

Для планирования используют среднее значение за последние 3-5 спринтов. Это сглаживает случайные колебания и дает реалистичный прогноз производительности.

Пример расчета среднего velocity

При планировании следующего спринта команда может ориентироваться на 30-32 сторипоинта. Это реалистичный объем работы, основанный на исторических данных, а не на оптимистичных предположениях.

Зачем нужен velocity команде

Метрика решает три ключевые задачи: планирование спринтов, прогнозирование релизов и управление ожиданиями стейкхолдеров. Разберем каждую подробно.

Планирование спринта

Сколько задач брать в спринт? Без velocity это лотерея. Со средним показателем скорости команда знает свою реальную пропускную способность.

Команда с velocity 30 SP не берет в спринт задачи на 50 пунктов. Иначе гарантированный провал, стресс и переработки. Вместо этого выбирают задачи примерно на 30 SP — с небольшим запасом или без него, в зависимости от рисков.

Прогнозирование релизов

В бэклоге 200 сторипоинтов до следующего релиза. Velocity команды — 30 SP за спринт. Простая математика: нужно примерно 6-7 спринтов до релиза.

Конечно, это приблизительный прогноз. Приоритеты меняются, задачи переоцениваются, появляются новые. Но это лучше, чем вообще никакого прогноза или прогноз из пальца.

Управление ожиданиями

Стейкхолдеры хотят невозможного? Покажите velocity и математику. Цифры отрезвляют лучше любых аргументов.

Вместо фразы «мы не успеем» используете конкретику: «При текущей скорости 28 SP за спринт на эту работу нужно 8 спринтов, а не 4 как планировалось». Это переводит разговор из эмоциональной плоскости в рациональную.

Факторы, влияющие на velocity

Скорость команды не константа. Она меняется под влиянием множества факторов — одни контролируемые, другие нет.

Состав команды

Новый участник снижает velocity на первых порах. Ему нужно время на адаптацию, изучение кодовой базы, процессов. Уход опытного разработчика тоже замедляет команду — теряется экспертиза.

Это нормально и предсказуемо. Главное — не паниковать при временном падении производительности и дать команде время стабилизироваться.

Технический долг

Накопленный технический долг как снежный ком: каждая новая фича требует все больше времени. Velocity постепенно падает, хотя команда работает с той же интенсивностью.

Решение — регулярно закладывать в спринт время на рефакторинг. Обычно 10-20% от velocity. Это инвестиция в стабильную скорость разработки в будущем.

Внешние зависимости

Ждем ответа от внешней команды? Velocity падает. Блокирующий баг в сторонней библиотеке? Velocity падает. Согласование с юристами затягивается? Угадайте, что происходит с velocity.

Эти факторы сложно устранить полностью. Но их можно учитывать при планировании — закладывать буфер времени на решение внешних блокеров.

Изменение оценок

Команда научилась лучше оценивать — velocity может измениться. Не потому что работают быстрее или медленнее, а потому что изменилась шкала измерения.

Раньше на задачу ставили 8 SP, теперь понимают что это реально 13 SP. Velocity в сторипоинтах снизится, хотя фактическая скорость осталась прежней. Поэтому важно отслеживать не только цифры, но и контекст за ними.

Типичные ошибки измерения velocity

Большинство команд допускают одни и те же ошибки при работе с velocity. Это превращает полезную метрику в источник проблем.

Использование velocity для сравнения команд

Команда А делает 40 SP за спринт, команда Б — только 25 SP. Значит А эффективнее? Нет.

Сторипоинты субъективны. Что одна команда оценивает в 5 пунктов, другая оценит в 8. Сложность проектов разная, технологические стеки разные, контекст разный. Сравнивать velocity между командами бессмысленно и вредно.

Давление на увеличение velocity

Менеджмент требует повышать velocity каждый спринт — команда начинает завышать оценки. Задача на 5 SP превращается в 8 SP, чтобы показать рост показателя.

Результат? Velocity растет на бумаге, а реальная скорость не меняется. Метрика теряет смысл, планирование становится невозможным. Команда играет в цифры вместо того, чтобы создавать продукт.

Включение незавершенных задач

Задача сделана на 90%? Ее нельзя включать в velocity. Либо задача готова полностью, либо не готова — третьего не дано.

Частичное выполнение размывает метрику. Непонятно, сколько на самом деле команда способна завершить за спринт. А значит невозможно адекватно планировать следующую итерацию.

Игнорирование трендов

Velocity падает три спринта подряд — команда игнорирует это как временную флуктуацию. А на самом деле нарастает технический долг или появилась системная проблема.

Метрику нужно не просто измерять, но и анализировать. Стабильное снижение или резкие колебания — сигнал разобраться в причинах.

Планирование на максимум

Максимальный velocity за последние спринты был 38 SP. Команда планирует следующий спринт на 38 пунктов. Это ошибка.

Планируйте на средний velocity, а не на пиковый. Пик — это исключение, которое сложилось благодаря удачному стечению обстоятельств. Рассчитывать на повторение исключения — прямой путь к срыву спринта.

Практика планирования по velocity

Теория бесполезна без практического применения. Как именно использовать velocity при планировании реальных спринтов?

Шаг 1: Определите средний velocity

Возьмите последние 3-5 завершенных спринтов. Посчитайте средний показатель. Если команда новая, начните с консервативной оценки и корректируйте по мере накопления данных.

Шаг 2: Учтите риски текущего спринта

Будут отпуска? Снизьте планируемый velocity на 10-15%. Ожидаются внешние зависимости? Еще минус 10-20%. Новая технология? Заложите буфер.

Лучше взять меньше и выполнить, чем переоценить возможности и провалить спринт. Доверие стейкхолдеров важнее амбициозных планов.

Шаг 3: Выберите задачи из бэклога

Начните с задач высокого приоритета. Набирайте до тех пор, пока не достигнете планируемого velocity. Добавьте одну небольшую задачу как стретч-гоал на случай, если все пойдет идеально.

Шаг 4: Отслеживайте выполнение

Используйте burndown chart для отслеживания прогресса внутри спринта. Если к середине спринта выполнено меньше половины работы — сигнал о проблемах.

Не ждите конца спринта, чтобы обнаружить что не успеваете. Реагируйте на отклонения сразу: убирайте задачи с низким приоритетом, перераспределяйте нагрузку, зовите на помощь.

Шаг 5: Проводите ретроспективу

В конце спринта анализируйте не только что сделали, но и почему velocity отличается от прогноза. Это важнее самих цифр.

Velocity выше плана? Отлично, но почему? Задачи оказались проще? Команда работала эффективнее? Поняли это — можете воспроизвести. Velocity ниже? В чем причина? Внешние блокеры? Недооценка сложности? Учтите это в следующем спринте.

Заключение

Velocity — не магическая метрика, которая решит все проблемы планирования. Это просто инструмент измерения реальной скорости команды на основе исторических данных.

Используйте velocity для планирования спринтов и прогнозирования релизов. Не используйте для сравнения команд или оценки индивидуальной производительности. Отслеживайте тренды, адаптируйте планы под изменения, учитывайте контекст каждого спринта.

Главное — помните, что цифры на графиках не самоцель. Цель — создать работающий продукт и сделать это предсказуемо, без хаоса и авралов. Velocity помогает команде работать устойчиво, а не на пределе возможностей.