Команда работает, спринты идут один за другим, но планирование каждый раз превращается в угадайку: сколько задач реально успеем? Именно здесь на помощь приходит velocity scrum — метрика, которая превращает хаотичные оценки в обоснованные прогнозы. В этой статье вы узнаете, как правильно считать скорость команды, чего избегать при анализе и как применять velocity на практике.
Что такое velocity в Scrum и зачем он нужен
Определение и базовая логика метрики
Velocity — это количество story points, завершённых командой за один спринт. Если в первом спринте команда закрыла задачи на 34 поинта, во втором — на 38, в третьем — на 36, то средняя скорость составляет около 36 story points за итерацию. Именно это среднее значение и становится основой для планирования следующего спринта.
Важно понять принципиальный момент: velocity — это не показатель эффективности отдельного разработчика и не KPI для руководителя. Это инструмент прогнозирования для команды. Путаница здесь приводит к токсичной гонке за цифрами вместо реальной пользы.
Как velocity связан со спринтом и бэклогом
Чтобы метрика работала, нужна здоровая основа: чёткие спринты с фиксированной длительностью и правильно оцененный бэклог. Если вы ещё не разобрались с устройством итераций, рекомендую прочитать Что такое спринт в Scrum: полное руководство для менеджеров и команд — там подробно разобраны структура, длина и ключевые события спринта.
Связь проста: чем стабильнее спринты по составу команды и длительности, тем точнее прогноз. Если в одном спринте участвуют 5 человек, а в следующем — 3, сравнивать velocity некорректно. Это как сравнивать скорость автобуса с разным количеством пассажиров и называть это «производительностью маршрута».
Как правильно считать velocity scrum
Формула расчёта и выбор периода
Формула элементарна: сложите story points всех завершённых задач за спринт — это ваш velocity за итерацию. Для планирования берите среднее значение за 3–5 последних спринтов. Не берите меньше трёх: одна аномалия (праздники, болезни, запуск нового инструмента) исказит картину.
Практический совет: если спринты сильно отличаются друг от друга — например, разброс от 20 до 60 поинтов — не усредняйте слепо. Разберитесь в причинах колебаний. Скорее всего, проблема либо в оценке задач, либо в нестабильном составе команды, либо в накопленном техдолге, который периодически «взрывается».
Частые ошибки при измерении скорости
Антипример номер один: считать в velocity задачи, которые «почти готовы». В Scrum задача либо done по definition of done, либо нет. Включение незавершённых историй в расчёт — это мягкий самообман, который разрушает весь смысл метрики.
Антипример номер два: использовать velocity для сравнения разных команд. Одна команда оценивает задачу в 3 поинта, другая — в 8. Это не значит, что вторая работает медленнее. Story points субъективны и калиброваны внутри каждой конкретной команды.
Антипример номер три — особенно распространён у фрилансеров и небольших команд: начинать считать velocity с первого же спринта и сразу делать жёсткие обязательства перед клиентом. Дайте метрике «устояться» минимум за 3 итерации, прежде чем обещать конкретные сроки.
Как применять velocity для планирования и управления командой
Планирование спринта на основе скорости
Зная среднюю скорость, вы можете обоснованно отвечать на вопрос «что войдёт в следующий спринт?». Если средний velocity — 40 поинтов, а Product Owner хочет добавить задачи на 70 — это уже не переговоры, а математика. Вы просто не успеете, и это не мнение, а прогноз на основе данных.
Для руководителей небольших команд это особенно ценно: вместо авторитарного «справимся» или робкого «постараемся» появляется конкретный разговор о приоритетах. Кстати, чтобы такие разговоры шли продуктивно, важно понимать Роли в Scrum: кто за что отвечает и почему без чёткого разделения проект рассыпается — особенно разграничение ответственности между Scrum Master, Product Owner и командой разработки.
Velocity как сигнал о здоровье команды
Устойчивое снижение velocity на протяжении нескольких спринтов — это диагностический сигнал, а не повод для паники или давления. Возможные причины: накопленный технический долг, выгорание, размытые требования, слишком крупные задачи без декомпозиции.
Резкий рост velocity тоже должен насторожить. Иногда это результат реального прогресса, но чаще — признак того, что команда начала занижать оценки задач или закрывать истории без должного качества. В отличие от канбан-методологии, где поток задач непрерывен и метрикой служит cycle time, в Scrum velocity даёт чёткий срез per итерацию — используйте это преимущество для регулярной ретроспективной диагностики.
Velocity для фрилансеров и малых команд: особенности применения
Адаптация метрики под небольшой масштаб
Если вы работаете соло или в команде из 2–3 человек, классический velocity scrum может казаться избыточным. Но даже в таком формате отслеживание скорости — это мощный инструмент для честного диалога с клиентом о сроках и объёмах.
Упрощённый вариант: используйте story points для оценки задач в бэклоге (например, по шкале 1–2–3–5–8) и фиксируйте, сколько поинтов закрываете за неделю или за двухнедельный цикл. Уже после 3–4 таких циклов у вас появится достаточно данных для точного прогноза.
Интеграция velocity в регулярные процессы
Главное правило: velocity работает только тогда, когда его считают системно, а не от случая к случаю. Сделайте обзор скорости частью вашей sprint review или еженедельного ретро. Занимает это 5–10 минут, но даёт чёткое понимание динамики команды.
Если ваши спринты неравномерны по длине или состав задач слишком разнородный — начните с упрощения: зафиксируйте длину итерации, договоритесь о шкале оценок, и уже через месяц у вас будет рабочая метрика.
Часто задаваемые вопросы
Как быстро можно начать использовать velocity в команде?
Технически — с первого же спринта, если у вас уже есть story points и definition of done. Но делать прогнозы на основе velocity имеет смысл только после 3–5 завершённых итераций. До этого используйте данные как ориентир, не как жёсткое обязательство.
Что делать, если velocity сильно колеблется от спринта к спринту?
Сначала исключите внешние факторы: праздники, болезни, смена состава команды. Если их нет — ищите проблему в процессе: размытые критерии готовности, задачи без декомпозиции, нестабильный бэклог. Цель — не идеальный velocity, а понимание причин колебаний.
Можно ли использовать velocity для оценки работы сотрудников?
Нет, и это принципиально. Velocity — командная метрика. Использование её для оценки отдельных людей провоцирует накрутку поинтов и разрушает доверие в команде. Для индивидуальной оценки используйте другие инструменты: качество кода, вклад в ретроспективу, соблюдение договорённостей.
Чем velocity отличается от throughput в канбан?
Throughput в канбан — это количество задач, закрытых за период времени, без привязки к итерациям. Velocity в Scrum — количество story points за спринт фиксированной длины. Оба показателя измеряют пропускную способность команды, но в разных системах координат. Если вы используете гибридный подход (например, канбан-доску в Trello с элементами Scrum), имеет смысл адаптировать метрику под свой контекст.
Отслеживать velocity scrum вручную в таблицах — занятие утомительное и ненадёжное. Гораздо удобнее использовать инструменты, которые делают это автоматически. Сервис Smartello.ru поддерживает оценку задач в story points прямо в карточках, а velocity команды можно отслеживать в несколько кликов — без Excel, без самодельных дашбордов и без потери данных между спринтами. Если вы хотите, чтобы планирование наконец стало предсказуемым, а не интуитивным — попробуйте Smartello как единую среду для управления итерациями и метриками команды.
Ваш комментарий будет первым