Что такое story points и почему их вообще придумали
Story points (стори поинты) - это условная единица измерения, которой в Agile-командах оценивают задачи не по времени, а по совокупной "тяжести": сложности, объёму и степени неопределённости.
По сути, команда отвечает не на вопрос "сколько часов уйдёт", а на другой:
"Насколько эта задача тяжёлая по сравнению с другими?"
Такая оценка отвязывает планирование от конкретных людей и их личной скорости работы. Один и тот же объём работы разработчик- senior сделает за 2 часа, middle - за 5, а новичок - за день. Но в терминах поинтов это одна и та же задача, один и тот же кусок сложности.
---
Почему оценка в часах плохо работает
Попытка оценивать всё в часах кажется логичной: есть календарь, дедлайны, зарплата привязана ко времени. Но у этого подхода есть несколько системных проблем.
1. Время всегда привязано к человеку
Одно и то же ТЗ у разных специалистов занимает разное количество времени. В итоге:
- оценки получаются "про человека", а не "про задачу";
- планирование становится привязанным к конкретным исполнителям;
- отпуска, перераспределение задач, выход новых сотрудников ломают весь прогноз.
Команда вместо планирования продукта начинает заниматься угадайкой: "А если это будет делать вот этот разработчик, то сколько часов? А если другой?"
2. Психологическое давление
Когда на задаче написано "4 часа", это легко превращается в личное обязательство:
"Если не уложился, значит, я плохо оценил / плохо работал".
Отсюда:
- стресс и чувство вины, если оценка не сошлась;
- желание "подстраховаться" и ставить завышенные цифры;
- напряжённые обсуждения на планировании и ретроспективе.
Человек начинает оценивать не задачу, а себя в этой задаче.
С поинтами этот эффект заметно слабее: цифра обозначает уровень сложности, а не фактическое время.
3. Часы плохо учитывают риски и неопределённость
В реальной работе постоянно всплывают:
- новые вводные;
- неожиданные зависимости от других команд;
- непредсказуемое поведение внешних сервисов и библиотек;
- блокеры, о которых никто не знал при оценке.
Попробуйте честно учесть это в часах - и либо получите раздутые сроки, либо регулярный срыв планов.
С условными единицами проще: можно заложить дополнительную сложность за риски и неизвестность.
---
Зачем нужны story points: реальные плюсы для команды
Переход на поинты - не просто модный ритуал из Scrum, а инструмент, который упрощает жизнь команде и менеджерам.
1. Задачи проще сравнивать между собой
С поинтами команда мыслит не абсолютными числами, а сравнением:
- "эта проще, чем та";
- "эта примерно такая же, как предыдущая сложная";
- "вот эта - явно больше и туманнее".
Со временем формируется общая внутренняя шкала:
1-2 поинта - простое, 3-5 - среднее, 8-13 и выше - крупное и мутное.
Чем больше у команды опыта оценок, тем быстрее и точнее она попадает в единый ритм - даже новички достаточно быстро подстраиваются под общую "интуицию сложности".
2. Риски и неопределённость учитываются честно
Пример:
Задача сама по себе понятная и несложная, но есть интеграция с внешним сервисом, который иногда "чудит".
В часах непонятно, что делать: закладывать большой запас (и выглядеть медленными) или рисковать с низкой оценкой.
В поинтах можно просто добавить "цену риска":
"обычно это на 3, но из‑за интеграции и возможных сюрпризов пусть будет 5".
Так неизвестность становится управляемой - она не прячется внутри чьей-то оптимистичной оценки, а явно отражается в числах.
3. Планирование проходит быстрее
Оценка в часах часто превращается в долгий спор:
"это 4 часа или 6? ну не 6, но и не 4... давайте 5?"
Команда тратит кучу времени на бессмысленную точность.
С поинтами обсуждение другое:
"это больше, чем вчерашняя тройка? Да. Меньше, чем та пятёрка? Да. Значит, тоже 5".
Выбор идёт из ограниченного набора значений, а не из бесконечной линейки часов. Оценка одной задачи занимает секунды, а не десятки минут.
4. Меньше стресса и больше фокуса на результате
Story points - это не таймер и не обещание "сделать за 4 часа". Это коллективная оценка сложности.
У людей меньше чувства вины за "непопадание" в часы и меньше страха ошибиться в оценке.
Фокус смещается с "укладываться в цифру любой ценой" на "сделать задачу максимально качественно и предсказуемо для команды".
В результате команда спокойнее относится к планированию и честнее говорит о рисках, не боясь, что "их посчитают медленными".
5. Становится проще планировать спринты
Когда команда поработает с поинтами несколько итераций, у неё появляется метрика velocity - условная "скорость" работы:
сколько поинтов в среднем команда закрывает за спринт.
Например:
- в одном спринте закрыли 26 поинтов,
- в другом - 28,
- в третьем - 24.
Можно считать, что средняя скорость команды - около 26-28 поинтов за спринт.
Дальше на планировании просто набирают задач на эту сумму поинтов.
Так команда перестаёт гадать, "сколько мы потянем", и опирается на собственную статистику.
---
Минусы и ограничения story points
Стори поинты - не волшебная таблетка, и у подхода есть недостатки.
1. Порог входа и сопротивление
Новичкам в Agile поначалу действительно кажется, что это "слишком абстрактно" и "непривязано к реальности". Некоторым менеджерам трудно отказаться от привычки видеть оценки именно в часах.
Важно понимать: поинты - не про красивую теорию, а про удобство планирования и честность в разговоре о сложности. Но к этому нужно немного привыкнуть.
2. Риск подменить поинты часами
Распространённая ошибка:
"1 поинт = 2 часа. Отлично, теперь будем считать часы через поинты".
Так делать нельзя - вы убиваете смысл метода. Поинты перестают быть оценкой сложности и снова превращаются в псевдочасы со всеми прежними проблемами.
Если так и хочется "пересчитать в часы", лучше работать напрямую с часами и не усложнять себе жизнь.
3. Некорректные сравнения между разными командами
Velocity - внутренняя метрика.
То, что одна команда делает 40 поинтов за спринт, а другая - 20, ровным счётом ничего не говорит об их эффективности.
У них может быть разная шкала поинтов, разный состав, разные типы задач. Сравнивать скорости разных команд по поинтам - бессмысленно и вредно: это подталкивает к натягиванию оценок "ради красоты отчёта".
---
Как оценивать задачи в story points: 3 популярных подхода
Существует несколько рабочих способов, как именно задавать шкалу и распределять поинты. Их можно использовать по отдельности или комбинировать.
1. Метод эталона: как в "38 попугаях"
Сначала команда выбирает одну понятную задачу, которую уже делала, - эталон.
Например:
"Сверстать простую лендинг-страницу по готовому макету без сложной логики" - давайте назовём это 3 поинта.
Дальше все остальные задачи оцениваются через сравнение с эталоном:
- проще и меньше, чем эталон - 1 или 2 поинта;
- примерно на том же уровне - 3;
- заметно больше и сложнее - 5, 8 и т.д.
Так команда выстраивает внутреннюю линейку сложности, как в мультфильме, где удава измеряли в попугаях.
2. Последовательность Фибоначчи
Часто используют ограниченный ряд чисел:
1, 2, 3, 5, 8, 13, 21, 34...
Чем больше задача, тем грубее шаг между значениями. Зачем так делать?
- мелкие задачи можно оценить точнее;
- крупные и очень сложные всё равно никто не оценит с точностью до часа, поэтому нет смысла спорить, "это 17 или 18".
Если команда понимает, что задача "где-то между 8 и 13", чаще всего выбирают большее значение - как маркер риска и объёма.
3. Размеры футболок
Иногда удобнее не числа, а категории:
XS, S, M, L, XL, XXL.
Особенно это заходит в продуктовых командах на раннем этапе, когда поинтами ещё никто не пользовался, а скорости как таковой нет.
Принцип тот же:
- XS - совсем простое и небольшое;
- S - чуть сложнее;
- M - стандартная средняя задача;
- L - уже ощутимо тяжёлая;
- XL / XXL - огромный кусок работы, который, возможно, лучше порезать на подзадачи.
Позже категории можно сопоставить с числовой шкалой поинтов, если такой переход станет необходим.
---
Как комбинируют методы на практике
На практике команды часто:
- берут Фибоначчи как основную числовую шкалу;
- заводят эталонные задачи для ключевых значений (например: 1, 3, 5, 8);
- для продуктов и маркетинга на старте используют размеры футболок, а потом постепенно маппят их к поинтам.
Важно не то, какая именно шкала у вас, а чтобы:
- все в команде одинаково понимали, что значит каждый размер / число;
- оценки были стабильными от спринта к спринту;
- метод помогал быстрее и честнее планировать.
---
Пошаговая инструкция: как начать оценивать задачи в story points
Шаг 1. Определите шкалу
Выберите, чем будете пользоваться:
- числа Фибоначчи: 1, 2, 3, 5, 8, 13, 21;
- простая шкала: 1, 2, 3, 5, 8;
- "футболки": XS-XL.
На старте лучше не брать слишком широкий диапазон, чтобы не запутать всех деталями. По мере взросления команды шкалу можно усложнять.
Шаг 2. Выберите эталонную задачу
Найдите одну-две задачи, которые команда хорошо помнит:
- понятный объём работы;
- типичный уровень сложности;
- нет экстремальных блокеров или аномальных рисков.
Назначьте им значения по шкале (например, "эта - 3, а вот эта, посложнее - 5") и договоритесь, что всё дальнейшее будете мерить "в сравнении с этими".
Шаг 3. Оцените первые задачи
Соберите бэклог задач на ближайший спринт и оцените их всей командой:
- сравнивайте каждую с эталонами;
- задавайте вопросы: "Эта сложнее или проще? В два раза или примерно так же?";
- если мнения сильно расходятся - обсуждайте, пока не придёте к общему.
Важно: не пытайтесь "попасть в идеальную цифру". На первых спринтах цель - выработать общее ощущение шкалы и научиться быстро сравнивать.
Шаг 4. Проведите спринт и замерьте velocity
Когда спринт завершится:
1. Посчитайте, сколько поинтов задач реально было завершено.
2. Отбросьте всё незавершённое - поинты считаются только по сделанным задачам.
3. Запишите результат как фактическую скорость спринта.
После нескольких итераций у вас появится более-менее стабильный коридор значений. Опираясь на него, можно планировать последующие спринты.
Шаг 5. Калибруйте оценки
По мере работы:
- смотрите, какие задачи регулярно оказываются "недооценёнными" или "перееоценёнными";
- обсуждайте это на ретроспективах;
- корректируйте свои эталоны и подход.
Не бойтесь пересматривать шкалу: это нормальный процесс взросления команды. Главное - делать это осознанно и совместно.
---
Дополнительные практические советы
Не привязывайте поинты к зарплате и KPI
Если начать оценивать людей по количеству закрытых поинтов, система исказится:
- задачи будут раздуваться в оценке;
- сложные задачи будут избегаться;
- командная честность при оценке пропадёт.
Поинты - инструмент планирования, а не измеритель эффективности конкретного человека.
Не используйте story points как оправдание хаоса
Сами по себе поинты не решат проблемы плохих требований, вечных переделок и отсутствия приоритетов.
Если в бэклоге хаос, задачи туманные и постоянно меняются - никакая система оценки не сделает планирование точным. Сначала нужно навести порядок в постановке задач.
Следите за размером задач
Если у вас регулярно появляются задачи на 21 или 34 поинта (или XXL), это сигнал:
скорее всего, такая задача слишком крупная и её нужно дробить.
Хорошая практика - стремиться к тому, чтобы большинство задач в спринте были в диапазоне 2-8 поинтов. Крупные "монолиты":
- сложно оценивать;
- тяжело двигать по доске;
- повышают риск незавершённых задач.
Используйте поинты для прогнозирования, а не для микроменеджмента
Когда появляется стабильная velocity, вы можете:
- примерно оценивать, на сколько спринтов растянется большой эпик;
- показывать бизнесу диапазоны сроков ("от 3 до 5 спринтов" вместо конкретной даты, высосанной из пальца);
- аргументированно говорить о том, что в текущий спринт физически не влезет ещё один крупный блок задач.
Но не стоит пытаться контролировать каждый день через поинты - для этого есть обычные статусы задач и ежедневные созвоны.
Регулярно объясняйте смысл поинтов новым людям
Приходят новички - и им нужно проговорить:
- что поинты - не часы;
- что их не используют для оценки зарплаты;
- что ошибаться в оценках нормально;
- что важен общий ритм команды, а не идеальная точность.
Если этого не делать, люди сами достроят картину, и чаще всего в не самую полезную сторону.
---
Краткий итог
- Story points - это условные единицы сложности, объёма и неопределённости задач, а не эквивалент часов.
- Они позволяют отвязать оценку от конкретных людей, честно учитывать риски и быстрее проводить планирование.
- Главные плюсы: удобное сравнение задач, честная работа с неопределённостью, снижение стресса и более предсказуемое планирование через показатель velocity.
- Минусы: нужен период привыкания, есть риск невольно превратить поинты в "часы под другим названием" и начать сравнивать команды между собой.
- Чтобы начать, достаточно: выбрать шкалу, определить эталоны, оценить первые задачи, замерить velocity и регулярно калибровать подход.
Если относиться к story points как к инструменту для совместного понимания сложности, а не как к ещё одной формальной метрике, они действительно упрощают жизнь и команде, и менеджерам, и бизнесу.
