Используешь ли Story points

Story Points в управлении проектами

Да, я использую story points, но с оговорками. Это полезный инструмент, если его правильно применять. Важно понимать, что это не точная наука, а инструмент для планирования спринтов и отслеживания velocity команды.

Что такое story points и зачем они нужны

Определение: Story points — это условная единица сложности задачи, которая учитывает:

• Объем работы
• Неопределенность (risk, unknowns)
• Сложность (техническая, организационная)
• Зависимости

Это НЕ часы работы. 5 points может быть 4 часа для senior'а и 2 дня для junior'а.

Шкала: Обычно используется Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 34, 55

• 1-2 points: очень простые задачи (фиксы, рефакторинг)
• 3-5 points: средние задачи (новые фичи с известным scope)
• 8-13 points: сложные задачи (неопределенность, много зависимостей)
• 21+ points: СЛИШКОМ большая задача, нужно разбить

Когда я использую story points

Сценарий 1: Спринт-планирование в Scrum

Я оцениваю каждую task перед спринтом:

• Беру task: "Реализовать фильтр по дате в админке"
• Обсуждаю с инженером: "Сколько points?"
• Инженер: "3 points, потому что UI есть, нужно только backend логика"
• Я: "OK, в спринт идет"

Зачем это нужно?

• Знаю, сколько работы в спринте
• Если спринт переполнен, убираю low-priority items
• Отслеживаю velocity (скорость команды)

Метрика velocity: Если команда в спринте делает 34 points, то:

• Следующий спринт планирую на 34-40 points
• Если нужно 50 points, добавляю людей или режу scope
• Если velocity падает, это сигнал (усталость, много багов, переоценка)

Сценарий 2: Roadmap-планирование на квартал

Оцениваю features для Q2:

• Feature A: 21 points
• Feature B: 34 points
• Feature C: 13 points
• Всего: 68 points

Знаю, что за квартал (12 недель, 3 спринта) команда из 4 человек сделает 34 * 3 * 0.8 = 81.6 points (0.8 — это коэффициент для непредвиденных задач, багов, встреч).

Вывод: Я могу взять Feature A + B + C (68 points) и еще немного.

Сценарий 3: Оценка новой фичи для бизнеса

Business спрашивает: "Когда будет фича X?"

Я:

1. Прошу инженеров оценить в points (8 points)
2. Делю на средний points/день: 8 / 2 = 4 дня
3. Добавляю buffer для других задач и багов: 4 дня * 1.5 = 6 дней
4. Говорю: "Примерно на неделе такой-то"

Как я ввожу story points в команду

Шаг 1: Planning Poker (оценка в группе)

На встрече:

1. Читаю task: "Интеграция с Stripe API для платежей"
2. Каждый инженер тихо выбирает карточку: 3, 5, 8, 13...
3. Открываем карточки одновременно
4. Если мнения разные (3 и 13), обсуждаем:
   • Кто выбрал 3: "Я думаю, у нас уже есть SDK"
   • Кто выбрал 13: "Я не видел документацию Stripe, много unknowns"
5. Пересчитываем: обычно сходимся на 5-8

Преимущество Planning Poker:

• Нет anchoring (когда первый высказанный number влияет на остальных)
• Обсуждение выявляет риски
• Senior видит, что junior недооценивает сложность

Шаг 2: Калибровка

В первые недели:

• Каждый инженер оценивает по-своему
• Один это 3 points, другой 8 points
• Я провожу регулярные ретро: "Почему мы разошлись в оценке?"
• Через месяц команда калибруется

Шаг 3: Отслеживание accuracy

Каждый спринт:

• Сравниваю оценку vs реальность
• Если estimated 5 points, но сделали за 2 дня = недооценили
• Если estimated 5 points, но сделали за неделю = переоценили
• Улучшаю будущие оценки

Опасности, которые я видел

Ошибка 1: Использование points вместо часов

Менеджер: "У нас 80 points в спринте, значит это 80 часов работы?"

Нет! Points — это не часы. 80 points может быть 60 часов для team A или 120 часов для team B.

Ошибка 2: Привязка points к bonuses / оценкам

Если я говорю:

• "Кто сделает 13 points, получит бонус"
• Инженеры начнут надувать оценки (15, 21, 34)
• Вся система сломается

Points должны быть objektiv, не связаны с деньгами.

Ошибка 3: Игнорирование выбросов

Если task estimated 5 points, но заняла неделю:

• Не говорю: "Твоя оценка была неправильная"
• Спрашиваю: "Что пошло не так? Были ли unknowns?"
• Может быть, нужно лучше писать задачи, чтобы было меньше surprises

Ошибка 4: Слишком большие tasks

Если task 34+ points:

• Это красный флаг
• Нужно разбить на несколько smaller tasks
• Слишком большие tasks = risk, потому что nobody knows estimate

Когда я НЕ использую story points

Случай 1: Maintenance / bugs

Баги часто оцениваю в часах, не points.

• Критичный баг: 4 часа (фиксим АСAP)
• Фича request: 13 points

Случай 2: Research / exploration

Если нужно разобраться в новой технологии:

• "Исследовать WebGL для графики" = 2 дня
• Points не подходит, потому что результат неопределен

Случай 3: Очень маленькие команды (1-2 человека)

В микрокоманде часто проще считать часы/дни.

• Story points дают overhead без бенефита

Пример из реального проекта

Проект: Реактивный redesign платформы (6 месяцев)

Квартал 1: Design + architecture (26 points)

• Новый дизайн в Figma: 5 points
• Архитектура компонентов: 8 points
• Setup проекта на React 18: 3 points
• Базовые компоненты: 10 points

Результат:

• Estimated velocity: 34 points/спринт
• Actual: 26 points (потому что много неясности в дизайне)
• Вывод: нужно лучше согласовать дизайн перед разработкой

Квартал 2-3: Фичи (108 points)

• Auth/registration: 8 points
• User dashboard: 13 points
• Analytics: 21 points
• Notifications: 13 points
• Social features: 21 points
• API интеграция: 21 points
• Admin panel: 11 points

Velocity улучшилась:

• Спринт 1: 28 points
• Спринт 2: 34 points
• Спринт 3: 37 points
• Спринт 4: 35 points

Почему velocity выросла?

• Дизайн был уже согласован
• Компоненты переиспользовались
• Команда привыкла
• Unknowns уменьшилась

Метрики, которые я отслеживаю

Мой совет

1. Используй story points для спринт-планирования, это главное применение
2. Не привязывай к деньгам или оценкам людей
3. Отслеживай velocity, но не преклоняйся перед ней (velocity может быть 34 point's, но это не значит, что все 34 points одинакового качества)
4. Пересчитывай estimate после спринта (learn from mistakes)
5. Разбивай большие tasks (13+ points — уже подозрительно)
6. Не используй points для баттл-планирования ("кто быстрее сделает 5 points")

В итоге, story points — это инструмент для планирования и communication между PM и Engineering. Если используешь правильно, экономишь месяцы на плохом планировании и риск в спринтах. Если используешь неправильно, это just theater без ценности.