Что такое Скорость команды

Скорость команды

(англ. velocity) — это метрика в Scrum, которая показывает, сколько условных единиц работы (чаще всего стори-поинтов) команда разработки завершает за один спринт. Это конкретный результат, который подсчитывают после завершения каждого цикла

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

Пример использования термина

«Как-то на ретроспективе мы с удивлением заметили, что наша скорость команды за два спринта упала почти вдвое: с привычных 55–60 до скромных 30 стори-поинтов. Вместо того, чтобы срочно «нагонять план», мы стали разбираться
в причинах. Оказалось, в обоих спринтах нам попались задачи с сильными внешними зависимостями: одна ждала данных от аналитического отдела, другая — API от внешнего поставщика. Мы простаивали, не имея возможности двигаться дальше. Это стало для нас уроком. Теперь на планировании мы специально помечаем такие задачи, заранее согласовываем сроки с другими командами
и стараемся не брать больше одной «зависимой» истории в спринт. Благодаря этому наша скорость снова выровнялась, но главное — мы перестали нервничать из-за срывов сроков, на которые не могли повлиять».

Что ещё нужно знать про Скорость команды

Как рассчитывают

Метрика складывается из стори-поинтов всех задач, которые сотрудники завершили в спринте. Если задача на 90% выполнена, но не прошла код-ревью или тестирование, её стори-поинты не считают.

👉🏻 Стори-поинты — это относительные единицы измерения объёма работы. Представьте, что вы архитектор и оцениваете сложность проектов. Спроектировать беседку для сада — это один балл. Разработать план коттеджа — три балла, потому что нужно учесть больше нюансов. А вот создать проект многоэтажного жилого комплекса с паркингом, инфраструктурой и согласованиями — это восемь баллов

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

Вернёмся к скорости команды. Пример расчёта может быть таким:

За двухнедельный спринт завершили семь задач.

Таск А — 5 стори-поинтов (сократим их до «СП»)
Таск Б — 1 СП
Таск В — 3 СП
Таск Г — 8 СП
Таск Д — 2 СП
Таск Е — 3 СП
Таск Ж — 5 СП

Базовая (за один цикл) Velocity = 5+1+3+8+2+3+5 = 27 СП

Для расчёта часто используют среднюю Velocity: не за одну итерацию,
а за несколько, обычно три-пять последних спринтов. Это сглаживает случайные колебания. Например, в одном спринте могло быть много мелких задач, в другом выполнили одну крупную. Среднее значение даёт более объективную картину. Например, первый спринт дал 32 поинта, второй — 28, третий — 35. Среднее выходит около 32.

Для чего используют метрику

Основное применение скорости — реалистичное планирование спринтов. Зная свою среднюю скорость, команда может брать в работу такой объём задач, который действительно способна выполнить. Это снижает стресс и повышает предсказуемость, а ещё помогает назначать даты релизов.

Продакт-оунер с её помощью делает долгосрочные прогнозы. В бэклоге продукта есть 400 стори-поинтов. Команда в среднем закрывает 40 поинтов за спринт. Значит, на выполнение всего объёма работы нужно примерно десять итераций.

Команда использует скорость для самоанализа. Резкий спад или скачок
в показателях даёт сигнал, что нужно задаться вопросом: «Что именно поменялось в нашем рабочем процессе?». Возможно, в работу попали задачи со сложными внешними зависимостями. Или, наоборот, сотрудники нашли новый, более эффективный способ справляться с рутиной.

Как интерпретируют

Интерпретировать скорость нужно осторожно. Высокая скорость не всегда говорит об успехе. Иногда это означает, что команда занижает оценки, чтобы «набрать больше поинтов». С другой стороны, низкий показатель скорости не должен автоматически считаться тревожным сигналом. Возможно, в работу взяли несколько очень сложных и важных задач.

Важна не абсолютная цифра, а её стабильность. Если команда несколько спринтов подряд показывает скорость в диапазоне 35–45 поинтов — это хороший признак предсказуемости. Резкие скачки, например, 20 поинтов в одном спринте и 60
в другом, указывают на проблемы в планировании или оценке задач.

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

❗️ Метрику часто ошибочно принимают за показатель производительности. В результате команды начинают специально завышать оценки задач, чтобы итоговые цифры выглядели лучше. Основная же проблема метрики заключается в том, что она отвечает на вопрос, сколько сделали, но полностью игнорирует то, насколько это было ценно для конечного продукта и его пользователей

Сейчас появляются более практичные способы оценивать работу. Так, метрики потока (Cycle Time, Throughput, Work in Progress) показывают, сколько времени задача движется от начала до конца и сколько тасков команда завершает
за неделю. Эти цифры сложнее подделать.

Другой вариант, прогнозирование вероятностей, не даёт одну точную дату,
а показывает вероятный диапазон сроков, когда всё будет готово. Но самое важное изменение — это растущий фокус на метриках, которые показывают реальный результат для бизнеса. К ним относят, например, рост использования новой функции (Hit Ratio) или повышение удовлетворённости клиентов (NPS, CSAT).

Как повысить скорость команды

Лучше всего, когда по мере работы над проектом количество завершённых задач постепенно растёт. Но так бывает не всегда. Вот что можно сделать, чтобы улучшить показатели скорости:

Работать над качеством оценок. Если сотрудники регулярно переоценивают или недооценивают сложность тасков, скорость будет «прыгать». Проведение регулярных рефайнмент-сессий помогает лучше понимать задачи до начала спринта.

Сокращать непредвиденные простои. Если команда часто ждёт ответов от других отделов или сталкивается с блокирующими проблемами, это снижает скорость. Выявление и устранение таких узких мест делает работу более плавной.

Инвестировать в техническое совершенствование. Если автоматизировать тестирование, улучшить инструменты разработки, делать рефакторинг legacy-кода, то всё это со временем повышает скорость, сокращая время на рутинные операции.

А ещё могут сокращать количество встреч и добавлять буфер времени
на непредвиденное.