Русская версия подготовлена на основе моей статьи на Хабре: «5 причин, почему ваши Story Points не работают (и что делать)».
За семь лет воркшопов по Story Points я вижу одну и ту же картину: команды изучают технику, пробуют её несколько спринтов, затем постепенно скатываются к старым привычкам. На маленьком масштабе — одна команда, максимум три — Story Points выглядят отличным подходом. На текущем масштабе у меня совсем другая оптика: 47 команд, около 400 человек в IT; 60% используют Story Points, 40% живут без них. Самое интересное — эти 60% используют их каждый по-своему. Во всяких FAANG про Story Points почти ничего не слышали: максимум всплывают размеры в футболках.
Конверсия в нормальное использование Story Points после тренингов — примерно 20%. Инструмент сам по себе окей; проблемы начинаются, когда его тянут в неподходящие цели или запускают без условий для нормальной работы. Ну что, начинаем холивар?
1. Без скрам-мастера Story Points быстро деградируют
Проблема: Story Points — инструмент для фасилитации разговора о сложности, рисках и неопределённости. Без постоянного коучинга команды быстро превращают его в ритуал: поставить цифру и пойти дальше.
Что происходит: команда проходит тренинг, несколько спринтов оценивает задачи «правильно»: обсуждает детали, вытаскивает риски, выравнивает понимание. Потом процесс упрощается с разной степенью радикализации: участники молча ставят оценки, вопросов почти нет, общей картинки тоже.
Есть ещё один важный слой: по-хорошему Story Points работают вместе с вертикальной нарезкой задач. Поменять подход команды к нарезке — это минимум два месяца работы с командой плюс поддержка после. Получается, в каждую команду надо серьёзно инвестировать. С учётом того, что у каждой команды свои Story Points, инвестировать придётся сразу во много команд.
Что делать: если ресурсов на выделенных скрам-мастеров нет, посмотрите в сторону более простых подходов. 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 Story Points в следующем спринте. Это как с баскетбольной командой: средний результат 98 очков за игру не обещает 98 очков в следующем матче.
Что делать:
- Для долгосрочного планирования используйте среднюю velocity с пониманием вариативности: насколько вашу скорость колбасит. Смотрите скользящую метрику за последние 4–6 периодов.
- Для точных прогнозов используйте статистические методы на исторических данных, например Monte Carlo simulations. Данных при этом должно быть достаточно.
- Для разговоров с бизнесом давайте честные диапазоны с вероятностями вместо точных дат.
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 — для внутреннего планирования:
- обсуждать сложность и риски внутри команды;
- выравнивать понимание задач;
- вытаскивать скрытые допущения и зависимости.
Метрики потока — для прогнозирования и улучшения:
- давать бизнесу надёжные прогнозы;
- анализировать bottlenecks и проблемы процесса;
- принимать решения на объективных данных.
Evidence-based подход: как говорит автор #NoEstimates Vasco Duarte, попробуйте оба метода несколько спринтов и сравните точность прогнозов. Пусть данные покажут, что лучше работает в вашем контексте. Проверить можно в разных инструментах: например, Jira, YouTrack, Kaiten. Ещё вариант — выгрузить CSV/XLS из этих сервисов в predictable.team и сравнить.
Заключение
Story Points остаются полезным инструментом для команд, которые используют их по назначению: обсуждать и планировать работу внутри команды. Для надёжных прогнозов, улучшения процесса и масштабирования flow-метрики часто дают лучший результат с меньшими затратами. Поэтому, когда думаете, стоит ли на масштабе запускать обучение и переезд на Story Points, подумайте дважды.