Velocity и прогноз

Скорость команды — самая полезная и самая опасная метрика в Scrum: всё зависит от того, кто на неё смотрит.

Velocity (скорость) — сумма story points историй, полностью завершённых за спринт. Это эмпирический факт о прошлом, из которого команда строит прогноз на будущее.

Velocity не назначают и не планируют — её измеряют. Нельзя «поставить команде velocity 30», как нельзя поставить термометру задачу показывать плюс двадцать. Это показание прибора, а не цель.

Как её считают

Правило одно и оно жёсткое: засчитываются только истории, доведённые до Definition of Done. Не «код написан», не «осталось только тесты», не «на 90 процентов». Готово или не готово.

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

Команда «Платёжки», последние 5 спринтов

Спринт 10   23 поинта
Спринт 11   31
Спринт 12   26
Спринт 13   18   (двое болели, релиз-фриз)
Спринт 14   29

Среднее:   25,4
Диапазон:  18 … 31

Полезны здесь оба числа. Среднее даёт центр, диапазон — честную ширину неопределённости. Команда, у которой «в среднем 25», на деле выдаёт то 18, то 31, и планировать спринт под 31 — верный способ регулярно не доносить обещанное.

Прогноз диапазоном, а не точкой

Пришёл заказчик и спрашивает: «Когда будет готов личный кабинет?» В бэклоге на него 120 поинтов. Считаем.

Честный ответ: «от 5 до 7 спринтов, вероятнее всего шесть». Не «ровно 5». Ответ с диапазоном звучит менее уверенно и оттого нравится меньше — но он не разваливается через месяц, в отличие от точной даты, названной наугад.

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

Почему velocity нельзя делать KPI

Стоит менеджеру объявить: «Цель квартала — поднять velocity с 25 до 35», как метрика умирает. Не потому что команда бесчестная. Потому что она рациональная.

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

• Инфляция оценок. То, что раньше было тройкой, теперь пятёрка. Velocity выросла на 60%, скорость работы — ноль. Проверить это со стороны невозможно.
• Дробление ради счёта. Одна история на 8 превращается в три по 5. На бумаге плюс семь поинтов.
• Урезание качества. Тесты потом, рефакторинг потом, ревью по диагонали. Velocity взлетает на два спринта, потом ныряет под плинтус вместе с командой, тонущей в багах.
• Бегство от сложного. Команда перестаёт брать рискованные истории, которые могут не закрыться. Берёт мелочь, которую точно успеет. Бизнес-ценность падает, цифра растёт.

Velocity отвечает на вопрос «сколько мы, скорее всего, вывезем в следующем спринте». Она не отвечает на вопрос «хорошо ли работает команда». Для второго есть другие вещи: работающий продукт, довольные пользователи, отсутствие пожаров на проде.

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

Поинты — внутренняя валюта. У команды А эталонная двойка — это новый CRUD-эндпоинт, у команды Б — правка текста на кнопке. Обе оценивают честно, но их шкалы отличаются в разы.

Поэтому таблица вида «команда А — 40, команда Б — 22, подтянитесь» бессмысленна ровно так же, как вывод «в Японии зарплаты выше, потому что цифры в иенах крупнее». Единственное, что произойдёт после такой таблицы: команда Б за пару спринтов «догонит» команду А — умножив свои оценки на два.

Сравнивать velocity можно только с самой собой, у одной команды, во времени. И даже тут аккуратно: сменился состав, ушёл единственный человек, знающий биллинг, — старая velocity недействительна, набирайте статистику заново.

Как это работает

Практические правила, которые стоит держать в голове:

• Первые 2–3 спринта velocity бессмысленна. Команда ещё калибрует шкалу. Не стройте прогнозов на одном спринте.
• Берите последние 3–5 спринтов. Данные годичной давности — про другую команду и другой код.
• Отпуска считайте отдельно. Если в спринте работают трое из пяти, ожидаемо, что velocity просядет. Это не деградация, это арифметика.
• Провал в одном спринте — не тренд. Тренд — это три спринта подряд. Разбирайте на ретроспективе, а не на следующий день.
• Velocity — для команды. Она нужна ей самой, чтобы не набрать в спринт лишнего. Как только цифра уезжает в отчёт для руководства, начинайте волноваться.

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

• Засчитывать частично сделанное. «История почти готова, дадим ей 6 из 8» — и velocity перестаёт отражать поставленную ценность.
• Планировать спринт по лучшей velocity. Один раз вывезли 31 — и теперь всегда берём 31. Команда стабильно не доносит и стабильно чувствует себя провалившейся.
• Требовать роста. Velocity растёт сама, когда команда срабатывается и наводит порядок в коде. Требование роста даёт инфляцию оценок, а не рост.
• Строить таблицы команд. Гарантированный способ обесценить оценки во всей компании.
• Переносить velocity на новый состав. Пришли двое новичков — скорость сначала упадёт, потому что опытные тратят время на онбординг. Это нормально.
• Считать velocity мерой продуктивности. Можно закрыть 40 поинтов ненужных фич. Скорость высокая, толку ноль.

Итоги

• Velocity — сумма поинтов историй, доведённых до Done. Незавершённое даёт ноль.
• Она измеряется, а не назначается: это факт о прошлом, а не план на будущее.
• Прогноз давайте диапазоном («5–7 спринтов»), опираясь на 3–5 последних спринтов.
• KPI из velocity делать нельзя: команда контролирует и оценки, и результат, и метрика мгновенно инфлирует.
• Поинты — внутренняя валюта команды. Межкомандные сравнения бессмысленны.
• Инструмент нужен команде для планирования, а не руководству для оценки людей.