Что такое Story Points

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

Проблемы, которые мы решаем

1. Оценка сложности задач
   Story points позволяют оценивать не время, а сложность и объём работы. Это даёт более честное планирование и меньше иллюзий «уложимся за два дня».
2. Распределение рабочей нагрузки
   Задачи с более высокой оценкой требуют больше ресурсов. Story points помогают справедливо распределить задачи по команде и не перегружать отдельных людей.
3. Управление неопределенностью и рисками
   Story points учитывают технические риски, неясные требования и интеграции. Мы оцениваем усилия даже там, где точные часы предсказать невозможно.
4. Улучшение планирования и прогнозирования
   Зная velocity (сколько points команда реально закрывает за спринт), можно ответить на вопрос «когда примерно это будет готово?» на уровне спринтов и кварталов.
5. Коммуникация между командой и менеджментом
   Часы часто трактуются по‑разному: разработчик говорит «16 часов», менеджер слышит «два дня». Story points — общий абстрактный язык, который сложнее использовать против команды.
6. Идеальная оценка в неидеальном мире
   Встречи, мессенджеры, поддержка продакшена, срочные баги — это реальность. Часы, оцененные «в вакууме», почти всегда ломаются. Story points фиксируют усилия, а не календарное время.

Шкалы оценки

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

Числа Фибоначчи (рекомендуемый стандарт)

Типичная шкала: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 80, ∞
Почему это удобно:

• Чем больше число, тем сильнее растёт шаг — отражает рост неопределенности.
• Разработчику трудно отличить 21 от 22, но легко — 13 от 20.
• Очень крупные числа (40+) сами по себе сигнализируют: задачу нужно дробить.

T‑shirt sizes

Типичная шкала: XS, S, M, L, XL, XXL, ∞
Полезна на ранних стадиях, когда оценка очень грубая. Позже можно связать размеры с числами Фибоначчи.

Степени двойки

Типичная шкала: 1, 2, 4, 8, 16, 32, 64
Иногда используются, но скачки слишком резкие, чем дальше по шкале, тем сложнее рассуждать.

Как оценивать задачи

Принцип относительности

Задачи оцениваются относительно друг друга, а не относительно «абсолютного» времени.

1. Выбираем одну знакомую задачу как reference story (например, 5 points).
   1. реальная задача из прошлого, которую:
      1. уже сделали;
      2. хорошо помнят;
      3. оценили и не считали ошибкой
   2. служат «якорями» для оценки новых задач, так вы выравниваете восприятие шкалы внутри команды
2. Все новые задачи сравниваем с ней:
   1. проще → 2–3 points
   2. сопоставима → 5 points
   3. значительно сложнее → 8–13 points

Так шкала не «привязана к человеку» и переживает смену людей в команде.

Что учитывать в оценке

При оценке смотрим на:

• Объем работы: сколько кода, тестов, изменений в схемах, конфигурации.
• Техническая сложность: новые технологии, сложные алгоритмы, рефакторинг.
• Риски: миграции, нестабильные внешние сервисы, сложная бизнес‑логика.
• Неопределенность: насколько понятны требования, есть ли вопросы к PO/аналитикам.
• Зависимости: ждём других команд? зависит от релиза соседнего сервиса?

Story points — это именно effort (усилия), а не duration (длительность по календарю).

Ключевые отличия от часов

Мини‑пример: часы против points

Оценка в часах:

• Dev A: «12 часов»
• Dev B: «24 часа»
• Менеджер: «Окей, среднее 18, значит сделаете к середине недели»

Через неделю: баги, встречи, поддержка — 18 часов превращаются в 3–5 дней календаря, все недовольны.

Оценка в Story Points:

• Dev A: «5 points»
• Dev B: «8 points»
• Команда обсуждает риски и детали, приходят к «8 points»
• Менеджер знает: при velocity 20 points за спринт задача — примерно 40% спринта. Вопрос звучит уже как «влезет в ближайший спринт?» — и на него есть честный ответ.

Velocity: скорость команды

Velocity — это количество story points, которые команда реально завершила за спринт (согласно Definition of Done).
Пример:

• Спринт 1: завершено 18 points
• Спринт 2: завершено 22 points
• Спринт 3: завершено 20 points

Средняя velocity = (18 + 22 + 20) / 3 ≈ 20 points.

Для чего нужна velocity

• Понимать, сколько задач можно объективно брать в спринт.
• Прогнозировать сроки завершения крупных фич/эпиков.
• Видеть тренды: команда ускоряется, деградирует или скачет.

Использование для прогнозов

Если бэклог эпика ≈ 200 points, а средняя velocity = 25:

• 200 / 25 = 8 спринтов
• При 2‑недельных спринтах — примерно 16 недель (4 месяца) плюс разумный буфер.

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

Planning Poker пошагово

Planning Poker — групповая техника оценки задач, позволяющая команде прийти к консенсусу и одновременно поделиться знаниями.

Шаг 1: Подготовка (grooming)

До сессии Planning Poker:

• Очищаем и уточняем backlog.
• Формализуем требования (user stories, acceptance criteria).
• Выявляем и, по возможности, снимаем основные риски.
• Разбиваем слишком крупные задачи (13+ points) на несколько меньших.
• Готовим несколько reference stories разных размеров.

Шаг 2: Представление задачи

Кто‑то (обычно PO, SA или ведущий разработчик):

1. Кратко формулирует user story: «Как пользователь, я хочу … чтобы …»
2. Озвучивает контекст (почему это важно).
3. Объясняет критерии приёмки.

Цель — чтобы каждый понял, о чём задача, а не залезть в низкоуровневые детали.

Шаг 3: Вопросы и уточнения

Команда задаёт вопросы:

• Что уже реализовано, а что нужно делать с нуля?
• Нужны ли изменения в БД/кэше/инфраструктуре?
• Как это тестируем? Нужны ли автоматизированные тесты?
• Есть ли зависимости от других команд или внешних сервисов?

Если после обсуждения задача всё ещё «плавающая» — лучше сначала выделить spike/исследование.

Шаг 4: Скрытое голосование

Каждый участник (в рамках практики, be, fe, qa, etc) берёт карточку с числом из выбранной шкалы и одновременно показывает её.

Важно:

• Никто не озвучивает число до того, как показывают все.
• Никаких «я думаю 5, а вы?».

Это снижает влияние авторитетов и groupthink.

Шаг 5: Обсуждение расхождений

Если оценки отличаются:

• Слово получают те, у кого минимальная и максимальная оценка.
• Они объясняют, что именно учитывали: забытые риски, объём, зависимости.
• Остальные задают уточняющие вопросы.

Цель — не добиться «среднего числа», а сделать так, чтобы все понимали одну и ту же задачу.

Шаг 6: Повторное голосование

После короткого обсуждения можно скорректировать оценку или переголосовать.
Чаще всего оценки сходятся. Если нет — повторяем цикл, пока не придём к достаточно узкому диапазону (например, все в 3–5 points).

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

1. Не усредняйте оценки

Плохо:

• A: 3 points
• B: 8 points
• C: 5 points
• Итог: «Пусть будет 5»

Вы теряете информацию, почему B считает задачу сложнее. Это сигнал к обсуждению, а не к усреднению.

Хорошо:

• Даем высказаться минимуму и максимуму.
• После обсуждения либо все подтягиваются к меньшему числу (риски сняты), либо к большему (риски признаны реальными), либо задача делится.

2. Не меняйте оценки задним числом

Если на реализации выяснилось, что «оценили не туда» — оценку оставляем.

• Ошибки в обе стороны со временем компенсируются.
• Историческая velocity остаётся честной.
• Вместо переписывания оценок обсуждаем на ретро, почему ошиблись и как улучшить процесс.

3. Определитесь, как оцениваете баги

Варианты:

• Оценивать все баги.
• Не оценивать баги, возникшие в текущем спринте при разработке новой фичи.
• Не оценивать мелкие баги, но всё серьёзное — да.

Главное — договориться и делать последовательно, чтобы velocity не шумела из‑за изменения политики.

4. Оценка «0» и «1/2»

• «0» можно использовать для задач, которые почти ничего не требуют (типа переставить поле в форме).
• «1/2» удобно для микрозадач, чтобы не раздувать velocity пачкой «единичек».

Следите, чтобы микрозадачи не доминировали — это либо запах микроменеджмента, либо плохой разрез задач.

Распространённые ошибки

Ошибка 1: Превращать points в часы

«У нас 1 point = 4 часа» → через месяц это перестаёт работать.
Story points — это про относительные усилия, а не про фиксированное время. Связывая их жёстко с часами, вы ломаете смысл метода.

Ошибка 2: Слишком большие задачи

Если задача > 13 points, почти всегда её нужно дробить.
Проблемы крупных задач:

• Огромная неопределённость.
• Риск, что не войдёт в спринт.
• Сложно debug’ить и ревьюить.

Признак здорового бэклога: большинство задач в диапазоне 2–8 points.

Ошибка 3: Оценивать в одиночку

Когда один человек (обычно тимлид или PM) оценивает за всех, команда не делится знаниями, а риски не всплывают.

Групповая оценка дороже по времени, но окупается точностью и shared understanding.

Ошибка 4: Путать effort и duration

• Effort (points) — сколько работы и сложности.
• Duration (дни/недели) — сколько по календарю займет с учетом отвлечений, отпусков, поддержки.

Одна и та же задача в 5 points может занять 1 день или 3 дня в зависимости от контекста, но points не меняются.

Ошибка 5: Набивать спринт под завязку

Если ваша средняя velocity = 25 points, брать в спринт 25–27 points каждый раз — прямой путь к постоянным недовыполнениям.
Нормальная практика — планировать 80–90% от средней velocity, остальное оставить на непредвиденные баги и support.

Когда Story Points не подходят

Хорошие условия для points

• Команда работает итерациями (спринты 1–4 недели).
• Состав команды относительно стабилен.
• Требования меняются, но не каждый день.
• Есть потребность в прогнозах на месяцы вперёд.

Плохие условия

• Чистая поддержка продакшена с потоком непредсказуемых инцидентов.
• Проект с жестко фиксированным контрактом по часам.
• Очень маленькая команда (1 человек).
• R&D этап, где задачи формата «разберись, как вообще это сделать».

В таких случаях часто работают более простые подходы (канбан, WIP‑лимиты, простой учёт времени).

Чек‑лист внедрения

Неделя 1: Подготовка

• Выбрать шкалу (Fibonacci).
• Собрать 3–5 reference stories.
• Объяснить команде принципы: относительность, effort vs duration, не переводим points в часы.
• Запланировать 1–1.5 часа на первую сессию Planning Poker.

Неделя 2–3: Первый спринт

• Оценить задачи спринта Planning Poker‑ом.
• Не менять оценки после старта.
• В конце спринта посчитать velocity (только завершенные задачи).
• На ретро обсудить: что было ок, что бесило.

Месяц 1–2: Шлифовка

• Отследить стабильность velocity: очень ли прыгает.
• Обновить список reference stories.
• Выявить типовые ошибки оценок и обсудить, как их снижать.
• Настроить разумный буфер (планировать на 80–90% от средней velocity).

После 2–3 месяцев

• Velocity стабилизировалась ±10–15%.
• Команда более уверенно планирует спринты.
• Есть достаточно материала, чтобы отвечать на вопросы «когда примерно будет готово».

Краткий итог

• Story Points — это про относительные усилия, а не про часы.
• Planning Poker — это про командное понимание задачи, а не про красивое число.
• Velocity — это эмпирическая реальность вашей команды, не нужно её подгонять.
• Reference stories и стабильный процесс оценки важнее хитрых формул.
• Самое ценное в оценках — не цифры, а обсуждения, которые к этим цифрам приводят.

Полезные ссылки:

• Понимание Story Points: практики, примеры и методы – L‑TECH
• Story Points для оценки задач – WEEEK
• 10 вопросов про Planning Poker – ScrumTrek
• Planning poker online