Сторипоинты в разработке — что это такое, шкалы оценки и применение

Что такое сторипоинты?

Сторипоинты — это метрика сложности задачи, используемая в Scrum и других Agile-методологиях. Команда оценивает каждую задачу не в часах, а в относительных единицах: «эта задача вдвое сложнее эталонной». Такой подход нивелирует разницу в скорости разных разработчиков и фокусируется на сложности.

Происхождение термина

Понятие сторипоинтов возникло в начале 2000-х годов вместе с популяризацией Scrum. Одним из первых метод описал Рон Джеффрис в рамках Extreme Programming (XP). Идея заключалась в том, чтобы уйти от оценки в «человеко-часах», которая всегда неточна, к относительной сложности, которую команда определяет коллективно. Сейчас сторипоинты — стандарт индустрии для Agile-команд.

Факторы, учитываемые в сторипоинтах

При оценке в сторипоинтах команда учитывает три фактора: объём работы (количество кода, экранов, логики), сложность (технические вызовы, новые технологии) и неопределённость (неясные требования, риски). Один сторипоинт может означать «простая задача без рисков», а 8 — «сложная задача с высокой неопределённостью».

Шкалы сторипоинтов: как выбирать

Выбор шкалы сторипоинтов влияет на точность оценки и удобство планирования. Самая популярная шкала — последовательность Фибоначчи, но есть и альтернативы.

Почему Фибоначчи? Психология шкалы

Последовательность Фибоначчи выбрана не случайно. Разница между 1 и 2 минимальна (50%), а между 13 и 21 — значительна (62%). Это отражает реальность: маленькие задачи оцениваются точнее, крупные — с большим разбросом. Когда задача оценивается в 21 сторипоинт, команда понимает: «мы не знаем, сколько это займёт, но точно больше 13». Шкала Фибоначчи предотвращает ложную точность.

Эталонная задача — основа шкалы

Чтобы шкала работала, команда договаривается об эталоне: «задача X — это 1 сторипоинт». Обычно эталоном выбирают простую, хорошо знакомую задачу: «добавить текстовое поле на экран» или «исправить баг типа typo». Все остальные задачи оцениваются относительно эталона. Без эталона сторипоинты теряют смысл — каждый понимает единицу по-своему.

Velocity команды и прогнозирование

Velocity (скорость команды) — среднее количество сторипоинтов, которое команда закрывает за один спринт. Это ключевая метрика для прогнозирования сроков проекта.

Как считается velocity

Velocity считается по завершённым задачам: суммируются сторипоинты всех задач, которые команда успела доделать (definition of done выполнен). Незавершённые задачи не учитываются. Для точности берётся среднее за последние 3-5 спринтов. Например, если команда закрыла 20, 22, 18 и 24 сторипоинта за последние 4 спринта, velocity = 21 сп.

Прогнозирование через velocity

Зная velocity и общий объём бэклога в сторипоинтах, можно прогнозировать количество спринтов до релиза. Например, если в бэклоге 210 сторипоинтов, а velocity = 21, потребуется 10 спринтов. Это грубый прогноз, который уточняется по мере работы. Важно: velocity — это среднее, а не обязательство. Планируйте по нижней границе (18 сп), а не по средней.

Как повысить velocity

Velocity нельзя повысить приказом — это симптом здоровья процессов. Устойчивый рост velocity достигается через: снижение технического долга, улучшение процессов код-ревью, сокращение контекстных переключений, автоматизацию тестирования и CI/CD. Важно: velocity разных команд нельзя сравнивать — каждая команда определяет сторипоинты по-своему.

Сторипоинты vs часы: что и когда использовать

У сторипоинтов и часов разные цели, и выбор между ними зависит от контекста. Опытные команды используют оба подхода для разных задач.

Когда сторипоинты работают лучше

Сторипоинты незаменимы для планирования спринтов: они не зависят от того, кто будет делать задачу. Junior может делать 2 сп за день, senior — 4 сп, но оценка задачи остаётся 2 сп для обоих. Сторипоинты позволяют отслеживать командную производительность, не сравнивая разработчиков. Это снижает политическое давление и улучшает атмосферу в команде.

Когда часы необходимы

Часы нужны для внешних обязательств: контракты, сметы, отчёты для заказчика. Клиент хочет знать не «8 сторипоинтов», а «3 недели». Для конвертации сторипоинтов в часы используется historical conversion rate: команда знает, что 1 сп = примерно 4 часа работы. Конвертация должна быть прозрачной и основанной на данных, а не на догадках.

Комбинированный подход

Многие команды используют комбинированный подход: задачи оцениваются в сторипоинтах для планирования спринта, а затем менеджер конвертирует их в часы/дни для внешней отчётности. Важно не смешивать две системы в одном процессе: либо вы оцениваете в сторипоинтах и выводите время из velocity, либо оцениваете в часах напрямую.

Типичные ошибки при работе со сторипоинтами

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

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

Самая частая ошибка — команда договаривается: «1 сп = 4 часа». В этом случае сторипоинты теряют смысл и превращаются в часы с другим названием. Сторипоинты должны быть относительными, не привязанными ко времени. Если задача А вдвое сложнее задачи Б, она получает 2 сп, независимо от того, сколько часов на неё уйдёт.

Оценка post-factum

Когда задачу оценивают после её выполнения — это не оценка, а констатация. Сторипоинты должны назначаться до начала работы, в момент максимальной неопределённости. Post-factum оценка искажает velocity и не даёт пользы для планирования. Более того, она создаёт ложное ощущение точности.

Сравнение velocity разных команд

Сравнение velocity команды A и команды B — бессмысленное упражнение. Каждая команда определяет эталон и шкалу по-своему. Для одной команды 1 сп — это простая задача на час, для другой — на день. Сравнивать можно только velocity одной команды в динамике: растёт она или падает.

Неконсистентная шкала

Когда разные задачи с одинаковой сложностью получают разные сторипоинты, а более сложные — меньше, шкала ломается. Команда должна регулярно калибровать шкалу: раз в 3-6 спринтов пересматривать ретроспективно, насколько оценки соответствовали реальной сложности. Это улучшает консистентность оценок.