Story Points: что это, зачем нужны и как правильно оценивать задачи

Story Points (SP, сторипоинты) создали, чтобы уйти от тирании часовых оценок. Но без понимания принципов они превратились в бессмысленный ритуал. Команды тратят рабочее время на пересчёт баллов в дни, менеджеры требуют «увеличить velocity на 20%», а разработчики тихо ненавидят планирование.

В этой статье я разберу, что такое Story Points, как их считать, в чём их польза и почему они всё равно причиняют боль.

Story Points — это единица измерения, которой оценивают усилия команды для выполнения задачи. Не время, а именно усилия. Работает это так: команда выбирает эталон — одну задачу, которую уже выполняла, — и сравнивает с ней новые задачи. Если новая задача сложнее — ей дают больше баллов, если проще — меньше.

Что учитывают при оценке:

• Объём работы. Много кода? Дизайн? Тесты? Документация? Например, задача «Добавить форму регистрации» может включать фронтенд, бэкенд, валидацию, тесты — это увеличивает объём.
• Сложность. Нужны новые технологии? Сложная архитектура? Много условий? Например, интеграция с внешним API может быть сложнее, чем вёрстка страницы.
• Риски. Есть зависимости? Расплывчатое ТЗ? Нужны эксперименты? Если ТЗ расплывчатое, сторипоинтов обычно больше, потому что детали задачи придётся уточнять по ходу.

Важно: один SP не равен часу, дню или неделе. Это относительная мера. Можно потратить 3 дня на задачу в 5 SP, если там был неочевидный баг. Это нормально.

Идея №1. Уйти от «тирании часов». Если задача оценивается в часах, она автоматически привязывается к срокам. «Мы оценили в 8 часов, значит, к вечеру должно быть готово». Но разработка — не конвейер. Часто сложно предсказать, сколько времени займёт задача. SP дают возможность оценить сложность без жёсткой привязки к календарю.

Идея №2. Оценка делается командой, а не одним человеком. Это позволяет учесть разный опыт. Тот, кто знает код лучше, может оценить задачу дешевле. Тот, кто видит риски — дороже. Обсуждение приводит к общему пониманию. Оценку в сторипоинтах не присваивают конкретному сотруднику, потому что оценка распространяется сразу на всю команду.

Идея №3. Прогнозирование через Velocity. После каждого спринта команда смотрит, сколько SP она закрыла. Со временем появляется среднее значение — Velocity. Это помогает прогнозировать, сколько задач команда сможет взять в следующий спринт. В первые спринты количество SP может сильно колебаться, но со временем появляется среднее значение, ниже которого показатель опускается редко.

Идея №4. SP хорошо работают в условиях неопределённости. Оценка в сторипоинтах — часть подхода Extreme Programming. Однако сейчас подход ассоциируется со Scrum, хотя в основе этого фреймворка никогда не было SP. Причина — SP хорошо работает, когда даже опытные команды получают задачи, которые сложно привязать к конкретному времени. Относительная мера помогает упростить оценку.

Проблема 1. Менеджеры переводят SP в часы. Хотят знать, сколько времени займёт задача. И тогда суть подхода ломается. Если менеджер спрашивает «сколько часов в 5 SP?», значит, он не понял идею. Один из принципов подхода — не привязывать SP к часам, иначе протопчете дорогу в проектный ад. Но есть реальность, и в ней руководителям часто нужны понятные значения. В частности, они хотят знать, сколько времени закладывать на разработку. И если отвечать на эти вопросы, то получается, что суть подхода ломается и менеджеры всё равно переводят SP в человеко-часы. Полностью исключить время при работе с SP не получается.

Проблема 2. Гонка за Velocity. Команды начинают гнаться за цифрами. «Надо увеличить Velocity на 20%!». Это приводит к тому, что разработчики завышают оценки, чтобы «вписаться» в план, или, наоборот, занижают, чтобы казаться быстрее. Фокус смещается с ценности на производительность. Команды пытаются повысить показатели спринта, что повышает риск некачественной работы.

Проблема 3. Сравнение разных команд. Одна команда закрывает 30 SP за спринт, другая — 20. Руководитель думает, что вторая работает хуже. Но на самом деле первая может делать простые задачи, а вторая — сложные, но более ценные для бизнеса.

Проблема 4. SP не работают для рутины. Если команда делает только однотипные задачи, возня с оценкой становится бессмысленной. Проще считать количество задач.

Проблема 5. Требуется зрелая команда. Если разработчики не доверяют друг другу, боятся говорить «я не понял» или ставят оценки, глядя на начальника — система ломается.

Даже Рон Джеффрис, который придумал сторипоинты, признал, что ему отчасти жаль за свою «разработку». По его словам, многие гибкие команды неправильно используют SP: пытаются повысить показатели спринта, что повышает риск некачественной работы и смещает фокус с поставляемой ценности на повышение производительности.

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

Цель 1. Делать предварительные оценки. Когда в бэклоге много задач и нужно их приоритизировать, на первом этапе можно не вдаваться в детальную оценку и определять количество часов, а быстро обозначить размер задачи в Story Points. Это поможет быстрее отобрать список задач в работу. Затем, хоть это и противоречит сути SP, можно заняться детальной аналитикой и дать оценку по времени или просто фиксировать фактическое время после выполнения.

Цель 2. Вовлечь всех участников команды в обсуждение работы. Главная ценность процесса — совместное обсуждение сложности работы и чёткое понимание её содержания. Разные мнения участников не считаются ошибкой — наоборот, расхождения в оценках помогают выявить скрытые нюансы и прийти к общему видению. В этом и есть суть планирования: не слепое голосование, а осознанный диалог.

Например, разработчик поставил задаче «5» вместо ожидаемой «1», не зная, что основная работа была выполнена ранее, а ему нужно лишь внести небольшое изменение. Без контекста он мог потратить часы на анализ, но минутный разговор с командой сразу прояснил реальный объём работы.

Цель 3. Мотивировать дробить задачи. Story Points чаще используют при работе по Scrum, а если работа по Scrum, то она проходит короткими спринтами в одну-две недели. Если взять в спринт одну крупную задачу, то его итогом будет выполнение плана либо на 100%, либо на 0. Тогда и анализ скорости станет проблематичным, и накопление исторических данных будет бессмысленным. Обсуждение оценки в Story Points может упростить процесс. Команда введёт в привычку, что задачу нужно делить на части и чем больше этих частей, тем лучше и тем прозрачнее будет прогнозирование работы.

Почему это полезно:

• Станет понятно, что можно отложить — когда задача состоит из нескольких подзадач, можно их приоритизировать и выполнить самое важное для работы новой функциональности. Возможно, даже окажется, что какую-то из задач можно сделать после релиза на этапе доработок.
• Получится оценить выполнение плана и видеть, как появление новых участников или уход старых отражается на скорости команды.
• Заказчик видит, что процесс не стоит на месте — даже если не получилось выполнить все задачи, руководитель понимает, что уже выполнено и какую ценность получают пользователи.

Причём в некоторых командах становится даже не так важно, сколько SP в итоге поставит команда. Важнее, что у всех участников появилось единое понимание задачи со всеми её деталями.

Цель 4. Оценивать в SP другие критерии задачи. Story Points — это необязательно только про объём и сложность задачи. В этих же значениях можно, например, оценивать значимость задачи — насколько ощутимый результат принесёт та или иная функциональность.

Цель 5. Уменьшить давление на сотрудников. Один разработчик может сказать, что выполнил бы задачу за 5 часов, но её в итоге ставят на другого сотрудника, которому нужно больше времени. Из-за таких ситуаций выше риск выйти за дедлайн. При оценке в SP принято, чтобы вся команда приходила к единой оценке в SP, которая не учитывает количество часов. Поэтому сотрудники с разной скоростью могут работать в комфортном режиме.

Ещё один сценарий — использовать человеко-часы как временное явление, если команда новая. Так она хотя бы примерно будет понимать затраты на разные типы задач, иначе оценка работы в SP для сотрудника будет слишком непонятна. Затем уже можно отказаться от часов и полностью перейти на SP, если они более удобны для руководителей.

Плюс 1. Сравнивать легче, чем считать. Люди плохо предсказывают абсолютные величины, но хорошо сравнивают. Вместо количества часов проще сказать: «Это похоже на прошлую задачу в 5 SP, но чуть сложнее». Это снижает градус стресса на планировании.

Плюс 2. Уход от «подгонки под часы». Если начальник требует оценить задачу в часах, часто звучит: «Ну назовите хоть что-то!». А потом это «что-то» становится дедлайном. SP же — абстрактные единицы, которые не получится «прибить» к календарю. Опять же, это при условии, если в команде понимают, зачем им нужны сторипоинты, а не используют их просто потому, что «это стандарт».

Плюс 3. Учёт всех факторов, а не только кода. В SP неявно зашиты исследования, баги и коммуникации. В часах же часто оценивают только «время за ноутбуком», а потом оказывается, что ещё сверх этого времени пришлось тратить часы на координацию с другими отделами.

Недостаток 1. Сравнение с другими сотрудниками. Это касается компаний, где SP используют сразу несколько команд. Одна из них может выполнять за спринт 30 SP, другая — 20. И это может быть причиной, почему руководитель посчитает вторую команду неэффективной. На деле первая команда может решать более привычные задачи, пока вторая занимается нетипичными и теми, которые в итоге могут принести больше ценности для бизнеса.

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

Недостаток 3. Требуют зрелой команды. Если разработчики не доверяют друг другу, боятся сказать «я не понял задачу» или ставят SP, глядя на начальника — система ломается.

Недостаток 4. Легко скатиться в «фетишизацию чисел». Команды начинают спорить, ставить 3 или 5 SP, хотя разница условна, гнаться за velocity как за KPI, либо искусственно раздувать или занижать оценки, чтобы «вписаться в спринт». Из-за этого команда начинает поклоняться цифрам, забывая, что это всего лишь инструмент.

Метод Фибоначчи. Самый популярный. Последовательность: 1, 2, 3, 5, 8, 13, 21... Числа растут, чтобы подчеркнуть растущую неопределённость. Разрыв между 5 и 8 больше, чем между 2 и 3, что отражает риск ошибки в сложных задачах. Лучше не заходить за пределы 21 SP, ещё надежнее — не заходить дальше 13. Задачи, которые оценивают в 21 SP и выше, скорее всего, можно раздробить.

Метод футболок. XS (1), S (2-3), M (5), L (8), XL (13+) — «надо дробить». Быстро и интуитивно, особенно для новых команд. Подходит для первичного планирования. Минус — слишком грубый метод для мелких задач, и позже всё равно нужно переводить в числа для velocity.

Покер планирования. Каждый участник получает карты с числами Фибоначчи. После обсуждения задачи все одновременно показывают свои оценки. Если мнения расходятся — обсуждают и переголосовывают. Это не даёт доминировать одному мнению и выявляет недопонимание. Дополнительно можно использовать карту «?» на случай, если сотрудник совсем не понимает задачи. Это сигнал, что нужно больше деталей.

Плюсы: не даёт мнению одного сотрудника доминировать, выявляет недопонимание.
Минусы: может затягиваться, если команда любит спорить. Новички стесняются ставить высокие оценки.

Метод «38 попугаев». Отсылка к советскому мультфильму, где удава мерили в попугаях. Метафора относительности оценок. Можно вообще не привязываться к числам Фибоначчи или часам. На практике вместо попугаев может быть что угодно: торты, апельсины, кубики — единицу измерения можно адаптировать под деятельность компании.

Шаг 1. Выберите метод. Для новичков лучше использовать метод с футболками за счёт упрощённости и большей наглядности. Но особых требований нет — можно выбрать тот, который больше нравится команде.

Шаг 2. Договоритесь об эталоне. Без «якоря» все оценки будут плавать. Выберите 2-3 реальные задачи, которые команда уже делала:

• 1 SP → «Исправить опечатку на странице», просто и предсказуемо.
• 3 SP → «Добавить новое поле в форму», есть код, но без сложной логики.
• 5 SP → «Интеграция с внешним API», документация есть, но могут быть нюансы.

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

Шаг 3. Обсудите задачи и проведите декомпозицию. Оценивать можно только то, что понятно. Если задача в духе «сделать красиво» — разбейте на подзадачи.

Пример: задачу «Доработать корзину» разбить на:

• Добавить анимацию удаления товара (3 SP).
• Исправить баг с округлением суммы (2 SP).
• Оптимизировать запросы к БД (5 SP).

Если задача больше 21 SP — дробите дальше.

Шаг 4. Подведите итоги спринта. Если задача на 5 SP заняла 2 дня — обсудите, почему оценка была занижена, и пересмотрите SP для похожих задач. Смотрите на Velocity, чтобы понимать, сколько SP команда закрывает за спринт. По мере накопления исторических данных станет понятно, сколько спринтов понадобится для реализации той или иной функциональности, что повысит точность планирования. А если часть задач стабильно скачет с нескольких сторипоинтов до нескольких десятков, а команде редко удаётся выполнить план, то это повод пересмотреть подход к оценке.

Можно ли использовать SP без часов?
Да. Это и есть их суть. Но на практике менеджеры часто требуют перевода в часы. Важно объяснить, что SP — это про сложность, а не про время.

Сколько SP в одном часе?
Нисколько. SP — не часы. Если вы переводите SP в часы, вы делаете это неправильно.

Что делать, если оценки постоянно расходятся?
Это нормально. Обсуждайте. Если оценки расходятся — значит, задача неясна или у команды разное понимание. Это повод уточнить ТЗ.

Нужно ли использовать SP в Kanban?
Обычно нет. Kanban — про поток, а не про итерации. SP нужны для планирования спринтов.

• Story Points — относительная мера сложности, а не времени.
• Проблемы: перевод в часы, гонка за Velocity, сравнение команд, рутинные задачи, незрелые команды.
• Как оценивать: выбери метод (Фибоначчи, футболки, покер), договорись об эталоне, дроби большие задачи, подводи итоги.
• Когда полезны: предварительные оценки, вовлечение команды, мотивация дробить задачи, уменьшение давления.

Начни с малого: на следующем планировании попробуй оценить задачи не в часах, а в SP. Не переводи их в часы. Просто сравнивай задачи между собой. Если сложно — используй футболки (S, M, L). Смотри, как изменится атмосфера на планировании. Удачи.