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

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

Что такое Story Points

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

SP выступает в качестве альтернативы оценке в человеко-часах, которая жестко привязывает исполнителя к срокам. В отличие от человеко-часов сторипоинты относительны. Это значит, что их не привязывают к конкретному времени.

Команда оценивает не «сколько часов займет задача», а «насколько она громоздкая по сравнению с другими задачами».

Что учитывают перед тем, как назвать оценку:

• Объем работы — например, нужно ли писать много кода, создавать дизайн, тесты, документацию. Например, задача «Добавить форму регистрации» может включать фронтенд, бэкенд, валидацию, тесты — это увеличивает объем.

• Сложность — нужны ли новые технологии и сложная архитектура, много ли условий и сценариев. Например, интеграция с внешним API может быть сложнее, чем верстка страницы.

• Риски — есть ли зависимости от других задач или внешних систем, требует ли задача исследований или экспериментов. Например, если ТЗ расплывчатое, сторипоинтов обычно больше, потому что детали задачи придется уточнять по ходу.

Что еще стоит знать о Story Points

Несколько тезисов, которые помогут глубже понять особенности подхода:

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

→ Оценку в сторипоинтах делает вся команда, а не один человек — это позволяет учитывать разный опыт. Также после планирования и выставления оценки сторипоинты не присваивают конкретному сотруднику, потому что оценка распространяется сразу на всю команду.

→ Чтобы прогнозировать работу, после каждого спринта команда смотрит на Velocity — количество сторипоинтов, которое команда завершает за один спринт. Средний показатель основывается на исторических данных. То есть в первые спринты количество SP может сильно колебаться, но со временем появляется среднее значение, ниже которого показатель опускается редко.

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

→ У SP неоднозначная репутация — многие команды не понимают, как отказ от человеко-часов помогает процессам и облегчает планирование. И это небезосновательно, о чем мы сейчас поговорим.

«Каноническая» оценка в SP встречается редко

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

Тем не менее, полностью исключить время при работе с SP не получается.

Поэтому с абсолютной уверенностью говорить о пользе Story Points сложно. Где-то сторипоинты не приживаются и только мешают или вовсе накаляют обстановку в команде, где-то смысл подхода разбивается об непонимание менеджеров, руководителей и их вопросы в духе «почему мы три дня делаем задачу, которую оценили в 5 SP?» Или об непонимание самих разработчиков, особенно плохо знакомых с подходом, для которых SP — это просто ненужный элемент в коммуникации.

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

Но недостатки Story Points не делают их бесполезными

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

Мы посмотрели, что пишут об опыте работы со Story Points пользователи на зарубежных и российских площадках, в том числе на Хабре. Весь этот опыт мы разделили на несколько целей, для которых используют SP на самом деле:

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

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

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

Мотивировать дробить задачи. Story Points чаще используют при работе по Scrum, а если работа по Scrum, то она проходит короткими спринтами в одну-две недели. Если взять в спринт одну крупную задачу, то его итогом будет выполнение плана либо на 100%, либо на 0. Тогда и анализ скорости станет проблематичным, и накопление исторических данных будет бессмысленным. 

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

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

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

• Получится оценить выполнение плана и видеть, как появление новых участников или уход старых отражается на скорости команды.

• Заказчик видит, что процесс не стоит на месте — даже если не получилось выполнить все задачи, руководитель понимает, что уже выполнено и какую ценность получают пользователи.

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

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

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

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

Еще несколько плюсов Story Points

Еще три преимущества, которые стоит отметить:

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

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

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

Недостатки Story Points, о которых мы не сказали 

У сторипоинтов есть еще несколько минусов и рисков, которые стоит учитывать:

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

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

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

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

Теперь рассмотрим, как определить количество SP. Делать это можно по-разному, поэтому собрали основные методы.

Относительная оценка по Фибоначчи

Суть метода Фибоначчи в оценке SP с помощью прогрессии, при которой каждое следующее число равно сумме двух предыдущих. Прогрессия выглядит так:

Оценка по Фибоначчи популярна, потому что отражает растущую неопределенность. Чем сложнее задача, тем труднее точно оценить усилия. Разрыв между числами увеличивается (5 → 8 → 13), что подчеркивает «риск ошибки». Разница в числах делает оценку более понятной и точной. Если разница между задачей в 3SP и 4SP была бы не такой очевидной, то у задач в 3SP и 5SP она более явная.

Как и с любым методом ниже может возникнуть иллюзия абсолютной точности трудозатрат. То есть команды начинают думать, что 5 SP ровно в 1.67 раза сложнее, чем 3 SP. На самом деле, разница субъективна.

Покер планирования

Каждый участник получает карты с числами, часто из последовательности Фибоначчи. Затем команда обсуждает задачу, после чего все одновременно показывают свою оценку. Если мнения сильно разнятся, например, 3 против 8, участники объясняют свою оценку и переголосовывают.

Дополнительно можно использовать карту «?» на случай, если сотрудник совсем не понимает задачи. Это сигнал, что нужно больше деталей.

Плюсы:

• Не дает мнению одного сотрудника доминировать .

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

Минусы:

• Может затягиваться, если команда любит спорить.

• Новички стесняются ставить высокие оценки.

Метод оценки по размеру футболок

Оценка по аналогии с размерами одежды:

• XS (1 SP);

• S (2-3 SP);

• M (5 SP);

• L (8 SP);

• XL (13+ SP) — «надо дробить».

Метод подходит для первичного планирования или если команда только переходит на SP.

Плюсы:

• Быстро и интуитивно, особенно для новых команд.

• Меньше споров — нет иллюзии точности.

Минусы:

• Слишком грубый метод для мелких задач.

• Позже все равно нужно переводить в числа для velocity.

38 попугаев или любое другое обозначение

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

Из плюсов — как и метод с футболками, попугаи позволяют уйти в абсолютную абстрактность. Можно вообще не привязываться к числам Фибоначчи или часам. На практике вместо попугаев может быть что угодно: торты, апельсины, кубики — поэтому единицу измерения можно адаптировать под деятельность компании.

Как оценивать задачи в Story Points и какой инструмент поможет команде

Резюмируем подход работы со сторипоинтами.

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

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

• 1 SP → Например, «Исправить опечатку на странице», просто и предсказуемо.

• 3 SP → «Добавить новое поле в форму», есть код, но без сложной логики.

• 5 SP → «Интеграция с внешним API», документация есть, но могут быть нюансы.

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

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

Например, задачу «Доработать корзину» можно разбить на 3 части:

• Добавить анимацию удаления товара (3 SP).

• Исправить баг с округлением суммы (2 SP).

• Оптимизировать запросы к БД (5 SP).

Если задача все еще кажется слишком большой, а ее оценка больше 21 SP — дробите дальше.

Чтобы команда быстрее пришла к единому видению усилий, можно использовать покер планирования.

Шаг 4. Визуализируйте задачи. Это помогает наглядно увидеть, чем занимается команда во время спринта и какой объем она закрывает. Для визуализации подойдут системы для управления проектами. Одна из них — Kaiten, где есть разные инструменты. Вот несколько из них:

→ Отображение SP в карточке задачи. Для этого можно добавить поле «Размер» и ввести туда оценку в тех единицах, которые использует ваша команда. 

→ Поле с оценкой отображается как внутри карточки, так и на ее фасаде, за счет чего проще бегло пройтись взглядом по пространству и оценить текущий объем работ и готовность задач:

→ Задачи легко фильтровать по оценке. Для этого наверху колонки можно нажать на отдельную иконку и выбрать нужный тип задач:

→ Можно поставить ограничение на размер задач. Для этого в Kaiten есть WIP-лимиты. Обычно их используют, чтобы сотруднику не давали одновременно слишком много карточек, но в Kaiten лимиты можно настроить и на показатель размера задач. То есть если вы хотите, чтобы команда брала сколько угодно задач, но чтобы их общий размер был не больше 4 SP или другой единицы, то можете указать это в настройках колонки:

После этого Kaiten отобразит текущую загруженность команды. Если все в порядке, у колонки будет зеленая отметка, а если загруженность слишком высокая, то  вся колонка подсветится красным:

→ Можно ставить коллективную оценку. Инструмент может стать альтернативой покерному планированию, так как позволяет каждому сотруднику указать свою оценку. Добавить поле для оценки можно в настройках карточки. Для этого нужно создать нужное пользовательское поле и выбрать тип значений:

После настройки вы сможете выводить оценку на фасад карточки и проводить онлайн-голосование и принимать решение:

Шаг 5. Подведите итоги спринта. Если задача на 5 SP заняла 2 дня → обсудите, почему оценка была занижена, и пересмотрите SP для похожих задач. Также изучите показатели Velocity, чтобы понимать, сколько сторипоинтов команда закрывает за один спринт. 

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

Для отслеживания Velocity в Kaiten есть отдельный отчет, который называется «Скорость выполнения»:

Ваша команда использует Strory Points или человеко-часы?

Поделитесь своим опытом в комментариях — как оценивают задачи в вашей команде и нравится ли этот способ. Видите ли пользу от SP или человеко-часы надежнее? Интересно узнать мнение разных сторон.