За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — 47 команд, около 400 человек в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному. Да и в целом, во всяких FAANG-ах о Story Points почти ничего не слышали, максимум - про размеры в футболках.

Причем конверсия в правильное использование Story Points после тренингов составляет около 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей. Ну что, начинаем холивар?

1. Без скрам-мастера Story Points быстро деградируют

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

Что происходит: Команды проходят тренинг, несколько спринтов оценивают задачи "правильно", обсуждая детали и выявляя риски. Затем процесс упрощается c разной степенью радикализации: участники молча ставят оценки, не задавая вопросов и не выравнивая понимание.

Все это помножено на тот факт, что по-хорошему Story Points используются при вертикальной нарезке задач. Изменение подхода команды к нарезке задач требует от 2-х месяцев работы с командой + поддержка структуры после. То есть вам нужно много инвестировать в каждую команду (причем учитывая что для каждой команды SP разные, надо инвестировать во много команд сразу).

Что делать: Если нет ресурсов на выделенных скрам-мастеров, рассмотрите более простые подходы. Flow-метрики требуют меньше коучинга и дают объективные данные автоматически.

2. Story Points не отражают реальный поток работы

Проблема: Даже идеально оценённые задачи могут застревать в системе. Backlog Items "стареют" независимо от количества поставленных им Story Points. Задача в 3 Story Points может висеть в Code Review неделю, а задача в 8 — пройти весь цикл за день.

Что происходит: Story Points оценивают "размер" задачи, но не показывают, как работа движется через систему. Они не учитывают bottlenecks, зависимости, изменения приоритетов и другие системные факторы.

Что делать: Дополните Story Points метриками потока:

• Cycle Time — время от начала работы до завершения

• Throughput — количество завершенных задач за период

• Lead Time — время от запроса до доставки

• Aging — время жизни задачи (еще не завершенной) в системе

3. Story Points создают иллюзию точности

Проблема: Команды используют Story Points для точных краткосрочных прогнозов, хотя они для этого не предназначены. Исследования показывают: если каждой задаче поставить "1" вместо Story Points и считать throughput, прогнозы часто получаются такой же точности.

Что происходит: Средняя velocity в 20 Story Points не означает, что в следующем спринте будет выполнено ровно 20. Это как с баскетбольной командой: средний результат 98 очков за игру не гарантирует 98 в следующем матче.

Что делать:

• Для долгосрочного планирования: используйте среднюю velocity с пониманием её вариативности (насколько вашу скорость колбасит - скользящая метрика за последние 4-6 периодов).

• Для точных прогнозов: статистические методы на основе исторических данных (Monte Carlo симуляции). Причем дата поинтов должно быть много.

• Для ответов бизнесу: честные диапазоны с вероятностями, а не точные даты.

4. Story Points не масштабируются между командами

Проблема: В крупных организациях каждая команда "калибрует" Story Points по-своему. Одна считает 5 SP средней сложностью, другая — высокой. Это делает невозможным сравнение производительности или планирование на уровне продукта.

Что происходит: Без единых стандартов и постоянного выравнивания Story Points становятся "вавилонской башней" — каждая команда говорит на своём языке оценок.

Что делать: Для кросс-командного планирования используйте объективные метрики: Throughput, Cycle Time, Lead Time. Они не зависят от субъективной интерпретации и дают сравнимые данные.

5. Story Points не помогают улучшать процесс

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

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

Что делать: Анализируйте поток работы с помощью CFD (Cumulative Flow Diagrams), scatterplots и метрик aging. Это покажет реальные проблемы и возможности для улучшения.

Практический подход: разделение инструментов и целей

Проблема не в Story Points как таковых, а в смешивании инструментов и целей.

Story Points — для внутреннего планирования:

• Обсуждение сложности и рисков в команде

• Выравнивание понимания задач

• Выявление скрытых допущений и зависимостей

Метрики Потока — для прогнозирования и улучшения:

• Надёжные прогнозы для бизнеса

• Анализ bottlenecks и проблем процесса

• Объективные данные для принятия решений

Evidence-based подход: Как говорит автор #NoEstimates Vasco Duarte, попробуйте оба метода несколько спринтов, сравните точность прогнозов. Пусть данные покажут, что работает лучше в вашем контексте. Проверить можно на разных инструментах: например jira, youtrack, kaiten; а можно просто загрузить csv/xls из этих сервисов в predictable.team и сравнить.

Заключение

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

Статья: перевод с личного блога.