Story Points (сторипоинты) — это относительная единица оценки трудоёмкости работы над задачей в гибких методологиях разработки, особенно в Scrum. Вместо измерения в часах или днях, сторипоинты отражают сложность, объём работы, неопределённость и риски.

🔹 Зачем нужны Story Points

В agile-подходах, таких как Scrum и Kanban, важно планировать не по часам, а по способности команды доставлять ценность. Story Points позволяют:

• Избежать точных (и часто ошибочных) прогнозов в часах;

• Оценивать задачи относительно друг друга;

• Сравнивать задачи по сложности, а не по количеству строк кода или времени;

• Учесть факторы, которые невозможно точно спрогнозировать.

Это помогает сосредоточиться на скорости доставки и устойчивом ритме работы команды, а не на контроле времени.

🔹 Что учитывается при оценке в сторипоинтах

Story Points — это не просто сложность кода. Команда обычно учитывает:

1. Объём работы
   — сколько нужно сделать (новые экраны, интеграции, миграции и пр.)

2. Сложность реализации
   — насколько технически непростая задача (работа с API, архитектура, зависимости).

3. Неопределённость
   — насколько ясно понимание задачи, насколько она может "расползтись".

4. Риски и блокеры
   — есть ли зависимости от других команд, внешних поставщиков, систем.

5. Знание и опыт команды
   — делали ли это раньше, есть ли эксперты, известны ли паттерны.

🔹 Как работают относительные оценки

Сторипоинты — относительная шкала. Команда сначала выбирает эталонную задачу, например:

• Простая форма с валидацией = 3 SP

• Интеграция с новым API = 5 SP

• Новый модуль с авторизацией и правами = 8 SP

Все остальные задачи сравниваются с эталоном, а не оцениваются в абсолютных величинах.

Команда не говорит: «эта задача займёт 3 часа», она говорит: «эта задача в 2 раза сложнее, чем та, что мы оценили в 5».

🔹 Типичные шкалы оценки

Наиболее распространённые шкалы:

• Фибоначчи: 1, 2, 3, 5, 8, 13, 21...
  Используется для усиления различий между задачами.

• Пауэр-2: 1, 2, 4, 8, 16
  Используется, когда хотят более резко ограничить крупные задачи.

• T-Shirt sizes: XS, S, M, L, XL
  Используются на раннем этапе (до Story Points).

Фибоначчи наиболее популярен, потому что он заставляет думать о росте сложности, а не линейно увеличивать оценку.

🔹 Как происходит оценка — Planning Poker

Частый способ оценки — Planning Poker:

1. Каждый участник (разработчик, тестировщик, аналитик) получает набор карт со значениями (1, 2, 3, 5, 8...).

2. BA или PO озвучивает задачу.

3. Команда обсуждает детали.

4. Все одновременно показывают карту со своей оценкой.

5. Если оценки расходятся — обсуждают причину.

6. Повторяют до консенсуса.

Planning Poker помогает:

• Избежать давления мнения «самого опытного»;

• Повысить вовлечённость команды;

• Вскрыть «недоговорённости» по задаче.

🔹 Velocity (скорость команды)

Когда команда начала использовать Story Points, она может начать измерять Velocity — среднее количество сторипоинтов, которое команда завершает за спринт.

Например:

• В первом спринте команда сделала 20 SP,

• Во втором — 23,

• В третьем — 19.

Velocity ≈ 20 SP/спринт. Это помогает планировать будущие спринты: если в бэклоге на 60 SP, значит — это примерно 3 спринта.

Velocity:

• уникален для каждой команды (зависит от её состава, процессов, знаний);

• не должен использоваться для сравнения между командами;

• со временем стабилизируется.

🔹 Почему не в часах?

Проблемы оценки в часах:

• Разработчики переоценивают или недооценивают задачи;

• У разных специалистов разная скорость;

• Люди чувствуют давление, если не успели «в свои 6 часов»;

• Часы не учитывают неопределённость;

• Сложнее прогнозировать скорость команды (velocity).

Преимущества Story Points:

• Упор на результат, а не время;

• Повышается точность планирования;

• Фокус на ценности и сложности, а не на сроках.

🔹 Мифы и ошибки

1. Story Points = часы/дни
   ❌ Нельзя говорить «1 SP = 1 час». Это сбивает смысл относительной оценки.

2. Оценивает только техлид
   ❌ Story Points — это командное мнение. У всех есть свой взгляд.

3. BA/PM определяет Story Points
   ❌ Только команда разработки (вместе с QA, если надо) может адекватно оценить сложность.

4. Все задачи надо довести до 1 SP
   ❌ Мелкие задачи — перегруз бэклога. Лучше не дробить, а сделать разумные оценки.

5. Story Points нужны менеджеру
   ✅ Нет, они нужны команде, чтобы самоорганизоваться, планировать и развиваться.

🔹 Практические советы

• Не пытайтесь оценивать «всё идеально». Оценка — это инструмент, а не цель.

• Если задача получилась на 13+ SP — разбейте на подзадачи.

• Учитывайте не только dev, но и тестирование, код-ревью, документацию.

• Позвольте Velocity стабилизироваться — для этого нужно 3–5 спринтов.

• Не сравнивайте команды по Velocity — это вредная метрика для межкомандного анализа.

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