Долгих дней, приятных ночей! Вы когда-нибудь сталкивались с тем, что обещанные «три дня работы» превращались в две недели? Или получали от разработчиков оценку в часах, а потом выяснялось, что задача заняла втрое больше времени? Проблема не в том, что команда плохо работает. Проблема — в часах. Я Наталия Курченкова, IT Project Manager с 10+ лет опыта и сегодня разберу:
- Как объяснить Story Points даже скептически настроенному руководству
- Почему 1 SP ≠ 8 часам (и почему эту ошибку делают 90% команд)
- Как внедрить систему за 4 шага, даже если вы никогда не работали в Agile
Аналогия из жизни: Почему "часы" часто подводят?
Представьте, что вам нужно оценить время переезда в новый офис:
- Опытная команда грузчиков скажет: "2 часа! У нас есть тележки и лифт".
- Офис-менеджер без опыта скажет: "8 часов! Я буду делать всё вручную".
- Реальность: Сломался лифт, часть коробок не подписана → переезд занял 6 часов.
В чём проблема?
- Часы зависят от того, КТО делает задачу (грузчик vs менеджер).
- Часы не учитывают непредвиденности (сломанный лифт).
- Часы заставляют врать: Опасаясь санкций, грузчики назовут 4 часа "на всякий случай".
Вывод: Оценка в часах — это прогноз, который сильно зависит от исполнителя и форс-мажоров.
Что такое Story Points (SP)? Проще некуда!
Story Point (SP) — это условная единица, измеряющая ОТНОСИТЕЛЬНУЮ СЛОЖНОСТЬ задачи.
Как это работает?
- Выбираем "эталонную задачу": Самую простую, понятную всем. Например:
"Добавить кнопку 'Сохранить' на страницу профиля".
Договоритесь, что это 1 SP. - Сравниваем ВСЕ остальные задачи с эталоном:
Если задача чуть сложнее эталона → 2 SP
Если значительно сложнее (в 3 раза) → 3 SP
Если очень сложная, много неизвестных → 5 SP, 8 SP, 13 SP
Пример:
Важно: Цифры (1, 2, 3, 5, 8, 13) взяты из ряда Фибоначчи. Они подчеркивают, что точность снижается для сложных задач (нельзя сказать "в 6.78 раза сложнее").
Зачем это ВАМ и вашей КОМАНДЕ? 5 главных выгод
- Избавляемся от страха оценки:
Разработчики не говорят "часы" (боятся не уложиться). Они говорят: "Эта задача в 3 раза сложнее эталона". Это объективнее. - Учитываем риски автоматически:
Задача "Интеграция с гос.API" = 8 SP не потому, что она долгая, а потому что там много неизвестных (документация, согласования). SP включают эту неопределенность. - Сравниваем несравнимое:
Как оценить "Дизайн мобильного экрана" против "Настройки CI/CD"? В часах — никак. В SP — просто: Дизайн = 3 SP, CI/CD = 5 SP. - Прогнозируем сроки реалистичнее:
После 2-3 спринтов вы узнаете Velocity команды (сколько SP она делает за спринт). Например: "Команда стабильно делает ~20 SP за 2 недели". Значит, бэклог на 100 SP ≈ 5 спринтов (10 недель). - Фокусируемся на сути:
Оценка в SP требует коллективного обсуждения. Разработчики, тестировщики, аналитики вместе вскрывают подводные камни.
Как объяснить руководству, что SP это эффективный инструмент?
Руководство любит цифры и предсказуемость. Дайте им это.
Аргумент 1: SP снижают риски срыва сроков
Раньше мы давали оценки в часах. Ошибка составляла 60-200%. С SP мы учитываем сложность, объем и риски в одной цифре. Ошибка прогноза упала до 10-20% после 3 спринтов (когда появился Velocity).
Аргумент 2: SP ускоряют планирование
Раньше спор из-за часов ('Это 8 или 16 часов?') занимал часы. Сравнение задач с эталоном ('Это 3 или 5 SP?') занимает максимум 1 час. Мы тратим время на работу, а не на споры.
Аргумент 3: SP делают команду ответственнее
Когда команда сама оценивает сложность через SP, она чувствует ответственность за результат. Люди перестают говорить 'менеджер неверно оценил', а начинают говорить 'мы недоучли риски, давайте учтем их в следующий раз'.
Аргумент 4: SP защищают команду от нереалистичных ожиданий
Если стейкхолдер требует 'сделать 100 часов работы за 2 недели', это давление. Если же у команды Velocity = 20 SP/спринт, а бэклог = 100 SP, мы говорим: 'Это 5 спринтов (10 недель), иначе — риск качества'. Это конкретный разговор на данных.
Когда Story Points НЕ работают?
- Очень маленькие команды (1-2 человека): Там проще оценивать в часах.
- Рутинные/повторяющиеся задачи (например, деплой на прод): Лучше использовать стандартные временные блоки.
- Критические баги: Тут нужны часы/SLA ("Починить за 4 часа").
- Жёсткие waterfall-проекты с фиксированным бюджетом/сроками: SP не совместимы с подходом "всё расписать на год вперёд".
Важно: Если руководство требует "перевести SP в часы" — не делайте этого, это уничтожает смысл метода. Лучше покажите график Velocity и скажите: "20 SP = один наш спринт. Что войдёт в следующий спринт — решаем вместе на планировании".
Как внедрить SP за 4 шага
- Начните с обучения: 1 час митинга. Объясните:
"SP - про понимание сложности, а не конкретное время." - Выберите эталон вместе: Пусть команда сама выберет простую задачу = 1 SP.
- Оцените первый бэклог: Используйте Planning Poker (можно бесплатные онлайн-инструменты). Правило: обсуждаем расхождения, а не голосуем.
- Рассчитайте Velocity после 2-3 спринтов: Покажите команде график: "Смотрите, мы стабильно делаем ~25 SP. Значит, в следующий спринт возьмём задач на 20-25 SP".
Первые результаты:
- Через 2 спринта команда скажет: "Спорим меньше, понимаем задачи лучше".
- Через 3 спринта вы скажете стейкхолдерам: "Фича Х ≈ 50 SP. При нашей скорости 25 SP/спринт — это 2 спринта (4 недели)".
Итог: Главное о Story Points
Ключевая мысль для команды и руководства:
Story Points — это не про "точные цифры". Это про то, чтобы:
- Перестать врать себе и другим о сроках.
- Увидеть реальную сложность работы.
- Планировать на основе данных, а не интуиции.
Начните с малого — выберите эталон и оцените 5 задач. Остальное приложится.
Легко ли было ввести Story Points в работу на вашем проекте? Делитесь в комментариях.