Связано ли Velocity со Story Points

Да, Velocity напрямую и статистически связана с Story Points (SP), но это не прямая причинно-следственная связь, а инструментальная метрическая зависимость. Это один из краеугольных камней Agile-планирования, который часто неправильно понимают. Давайте разберем эту связь по полочкам.

1. Базовое определение связи

Velocity — это измеряемый показатель того, сколько Story Points команда стабильно завершает (делает "Done") за один итерационный цикл (спринт).

Story Points — это относительная оценка сложности, объема работы и/или неопределенности задачи (User Story). Это не время, а единица "емкости" работы.

Таким образом, формула базовой связи выглядит так:

Velocity = Σ(Story Points всех задач, переведенных в статус "Done" за спринт)

2. Ключевой характер связи: Историческая, а не прогнозная

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

• Story Points назначаются ДО спринта во время планирования, на основе сравнения сложности новых задач с уже известными (планирование покера).
• Velocity вычисляется ПОСЛЕ спринта как сумма выполненных SP. Это эмпирический факт, а не план.
• Связь становится полезной, когда Velocity стабилизируется (обычно после 3-5 спринтов). Стабильная Velocity позволяет использовать Story Points для прогнозирования.

# Упрощенная иллюстрация расчета и использования Velocity
completed_sprints = [
    {"sprint": 1, "completed_sp": 24},
    {"sprint": 2, "completed_sp": 28},
    {"sprint": 3, "completed_sp": 26},
]

# Рассчитываем среднюю Velocity (исторический факт)
total_sp = sum(sprint["completed_sp"] for sprint in completed_sprints)
average_velocity = total_sp / len(completed_sprints)  # = 26.0

# Используем Velocity для прогноза (не для жесткого плана!)
product_backlog_total_sp = 300
forecast_sprints = product_backlog_total_sp / average_velocity  # ≈ 11.5 спринтов

3. Для чего используется эта связь? Практическое применение

Связь Velocity и Story Points — это инструмент для эмпирического управления проектом:

1. Прогнозирование сроков и объема: Зная среднюю Velocity и общее количество SP в бэклоге, можно прогнозировать, сколько спринтов может потребоваться для реализации определенного объема функций.

    > **Важно:** Это прогноз с доверительным интервалом, а не жесткий дедлайн. "С вероятностью 85% мы завершим Scope X за 5-7 спринтов".

1. Планирование спринта: Во время Sprint Planning команда, зная свою историческую Velocity, выбирает из бэклога такие истории, общая сумма SP которых примерно соответствует этой Velocity. Это защищает команду от перегрузки.

2. Выявление проблем: Резкие изменения Velocity (не путать с постепенным ростом) — это сигнал для ретроспективы.

    *   **Velocity резко упала?** Возможные причины: технические долги, внешние блокировки, проблемы в команде, некачественная оценка SP.
    *   **Velocity резко выросла?** Возможно, изменился подход к оценке (стандартизация, повторяемость задач), либо оценки были изначально завышены.

4. Опасности и антипаттерны в использовании этой связи

Менеджеры, не до конца понимающие философию Agile, часто искажают эту связь:

• Сравнение команд по Velocity: Это абсолютно бессмысленно и вредно. Velocity — внутренняя метрика команды. Если одна команда имеет Velocity 50, а другая — 20, это не значит, что первая "лучше". У них абсолютно разные базисы для оценки Story Points.
• Использование Velocity как KPI для премирования: Это гарантированный путь к инфляции Story Points. Команда быстро поймет, что чем больше SP она "завершит", тем лучше ее показатели. Это уничтожает саму суть относительной оценки.
• Конвертация Velocity в человеко-часы: Заявление "1 SP = 8 часов, а Velocity = 30 SP, значит команда тратит 240 часов" — это фундаментальная ошибка. SP оценивают сложность, а не время. Такая конвертация возвращает к waterfall-подходу и дискредитирует гибкую методологию.
• Попытка постоянно наращивать Velocity: Цель — стабильная и предсказуемая Velocity, отражающая реальную производительность. Искусственное ее завышение ведет к выгоранию и падению качества.

5. Альтернативы и современный контекст

В некоторых фреймворках (например, Kanban) от связи Velocity-SP могут отказаться в пользу других метрик, более релевантных для непрерывного потока:

• Throughput (пропускная способность): количество завершенных задач за единицу времени.
• Cycle Time (время цикла): среднее время, которое задача проводит в работе (от старта до завершения).

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