За семь лет проведения воркшопов по 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 - подумайте дважды.
