Планирование спринта по данным: velocity без самообмана

Коротко. Velocity — количество работы, которое команда фактически завершает за спринт. Её единственное осмысленное применение — планирование объёма следующего спринта той же командой: если в среднем закрывается 30 единиц, планировать 45 бессмысленно. Всё остальное, что обычно делают с velocity, ломает её: сравнение команд между собой (оценки несопоставимы по определению), использование как показателя продуктивности и постановка цели «повысить velocity» — последнее гарантированно приводит к инфляции оценок, а не к росту результата. Для планирования полезнее смотреть не среднее, а диапазон последних спринтов и отдельно — сколько времени команда фактически имеет на работу.

Velocity — инструмент планирования объёма, а не измеритель продуктивности команды

Содержание

• Что такое velocity и чего она не измеряет
• Как использовать при планировании
• Почему нельзя сравнивать команды
• Что происходит, если сделать velocity целью
• Что смотреть вместе с velocity
• Реальная ёмкость команды
• Когда velocity бесполезна
• Чек-лист
• FAQ

Что такое velocity и чего она не измеряет

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

Что velocity измеряет: объём работы, который команда в этих единицах фактически довела до готовности за фиксированный период.

Чего она не измеряет:

• продуктивность. Оценки субъективны, и одна и та же работа в разных командах получит разные числа;
• ценность. Можно закрыть много задач, не сдвинув продукт;
• качество. Быстро закрытая работа с дефектами увеличивает velocity и уменьшает пользу;
• усилия людей. Это не показатель того, кто как работал.

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

Как использовать при планировании

Рабочая практика:

1. Возьмите последние 3–5 спринтов и посмотрите не среднее, а диапазон: минимум и максимум. Планировать разумно по нижней границе или чуть выше.
2. Учтите состав спринта. Отпуска, дежурства, новые люди, праздники — всё это уменьшает ёмкость, и velocity прошлых спринтов этого не знает.
3. Резервируйте место под неплановое. Инциденты и срочные запросы приходят всегда; спринт, забитый на 100% плановой работы, срывается по определению.
4. Не корректируйте оценки задним числом. Если задача оказалась вдвое сложнее, это информация для будущих оценок, а не повод переписать историю.
5. Считайте только завершённое. Задача, доведённая до 90%, добавляет ноль — иначе показатель теряет смысл.

Полезная привычка: смотреть на velocity вместе с тем, сколько работы перетекло из спринта в спринт. Стабильный перенос — признак, что планируется больше, чем возможно.

Почему нельзя сравнивать команды

Потому что единицы измерения у каждой команды свои. Оценка в story points — это соглашение внутри команды о относительной сложности, а не объективная величина. У одной команды «5» означает день работы, у другой — три дня.

Что происходит при сравнении: команды, у которых цифры ниже, начинают завышать оценки. Это самая быстрая и самая предсказуемая деформация процесса, и восстановить доверие к оценкам после неё сложно.

Отдельно: сравнение сотрудников внутри команды по «закрытым поинтам» разрушает совместную работу — становится невыгодно помогать и брать сложные задачи. Аргументы — метрики без наказания и метрики процессов команды.

Что происходит, если сделать velocity целью

Классический механизм искажения, описанный в законе Гудхарта:

• инфляция оценок. То, что раньше было «3», становится «5» — velocity растёт, работа та же;
• дробление задач. Больше задач, больше поинтов, тот же результат;
• избегание сложного. Задачи с неопределённостью портят статистику, их откладывают;
• срезание качества. Тесты, рефакторинг и документация уменьшают velocity — и первыми попадают под сокращение;
• исчезновение честности в оценках. А без честных оценок velocity перестаёт работать даже для планирования.

Практический вывод: velocity должна оставаться инструментом команды для себя, а не отчётным показателем наверх. Если её всё равно требуют, лучше отдавать вместе с контекстом: состав спринта, перенос, инциденты.

Что смотреть вместе с velocity

Набор, который даёт управляемую картину:

• предсказуемость. Насколько план спринта совпадает с фактом — часто важнее скорости;
• время прохождения задачи от начала работы до готовности: показывает, где задачи стоят в ожидании;
• объём незавершённой работы. Много начатого одновременно — главный источник задержек;
• доля неплановой работы. Если половина спринта уходит на срочное, планировать бессмысленно, нужно разбираться с потоком;
• нагрузка встречами. Реальное время на работу сильно меньше номинального: нагрузка встречами команды;
• стабильность ритма по неделям: разброс и стабильность.

Смотреть эти показатели корректнее на уровне команды, а не персонально: обезличенная аналитика сотрудников. Как выглядит картина нагрузки и фрагментации — в демо.

Реальная ёмкость команды

Частая причина систематического срыва спринтов — планирование от номинального времени. В двухнедельном спринте у разработчика не 80 часов работы: часть уходит на встречи, ревью, помощь коллегам, дежурства и возврат в контекст.

Практичный подход:

1. Посчитайте фактическое время на проектную работу за прошлые спринты — по данным, а не по ощущению: как анализировать рабочий день.
2. Уменьшите номинальную ёмкость на долю координации и неплановой работы.
3. Планируйте по этой цифре, а не по календарным часам.
4. Проверьте, есть ли у команды длинные неразорванные отрезки: без них сложные задачи не двигаются: дробление рабочего дня.

Когда velocity бесполезна

• Первые спринты новой команды. Данных нет, оценки не калиброваны.
• Постоянно меняющийся состав. Ёмкость меняется быстрее, чем накапливается статистика.
• Поток срочной работы. Если больше половины спринта — инциденты, планировать нечего, нужно менять процесс.
• Исследовательские задачи. Оценить неизвестное нельзя; такие задачи выносят в отдельный формат с таймбоксом: таймбоксинг.
• Когда velocity требуют наверх как показатель эффективности. В этом случае она перестаёт быть данными и становится отчётностью.

Чек-лист

• Velocity считается только по завершённым задачам.
• Для планирования берётся диапазон последних 3–5 спринтов, а не среднее.
• Учтены отпуска, дежурства, праздники и новые люди.
• В спринте есть резерв под неплановую работу.
• Оценки не корректируются задним числом.
• Velocity не сравнивается между командами и не используется персонально.
• Рядом отслеживаются предсказуемость, перенос работы и доля срочного.
• Ёмкость считается от фактического времени на работу, а не от календарного.

FAQ

Что такое velocity команды? Сумма оценок задач, завершённых за спринт. Показывает объём работы, который команда фактически доводит до готовности за период в своих единицах оценки.

Как использовать velocity при планировании спринта? Смотреть диапазон последних 3–5 спринтов и планировать по нижней границе, учитывая отпуска и дежурства, и оставляя резерв под неплановую работу.

Почему нельзя сравнивать velocity разных команд? Потому что единицы оценки — внутреннее соглашение команды, а не объективная величина. Сравнение приводит к завышению оценок, а не к росту результата.

Что будет, если поставить цель повысить velocity? Оценки начнут расти, задачи — дробиться, а качество и сложные задачи пострадают. Velocity вырастет, результат — нет.

Можно ли считать velocity по незавершённым задачам? Нет, тогда показатель теряет смысл: почти готовая задача не даёт ценности и не должна учитываться.

Что важнее velocity при планировании? Обычно предсказуемость — совпадение плана с фактом — и доля неплановой работы. Скорость без предсказуемости планировать не помогает.

Как учесть, что у разработчика в спринте не 80 часов работы? Считать фактическое время на проектную работу по прошлым спринтам и планировать от него, а не от календарной ёмкости.

Опубликовано: 12 августа 2026 г.