Story points: что это и как оценивать задачи

Story points — одна из самых обсуждаемых и неправильно понятых практик в Scrum. Их путают с часами, превращают в KPI и спорят о шкалах. Разберём по-честному: что это, зачем нужно и как команде начать оценивать задачи в story points без боли.

Что такое story points

Story points (стори-поинты) — это относительная оценка размера задачи. «Размер» здесь — это совокупность трёх вещей: объём работы, сложность и неопределённость/риск. Команда не считает минуты, а сравнивает: «эта задача примерно вдвое больше вон той».

Story points отвечают не на вопрос «сколько времени уйдёт?», а на вопрос «насколько эта задача больше другой?». Это сравнение, а не секундомер.

Почему не часы

Кажется, что часы понятнее. Но у оценки в часах три проблемы, которых нет у story points:

• Люди плохо оценивают абсолютное время. Зато хорошо сравнивают: что больше, что меньше.
• Часы давят. «4 часа» воспринимается как обещание, и команда занижает оценки, чтобы выглядеть быстрее.
• Часы у всех разные. Сеньор и джун потратят разное время, а размер задачи — один. Story points от исполнителя не зависят.

Зная средние story points за спринт (velocity), команда прогнозирует объём работы стабильнее, чем по часам.

Шкала Фибоначчи

Чаще всего для story points берут модифицированную шкалу Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Растущие промежутки — это не случайность: чем крупнее задача, тем выше неопределённость, и тонко различать «18 или 19» бессмысленно. Если задача тянет на 13+, её почти всегда стоит разбить на меньшие.

Покер планирования

Покер планирования (planning poker) — самый популярный способ оценивать командой:

1. Владелец продукта зачитывает задачу, команда задаёт вопросы.
2. Каждый одновременно называет свою оценку (карты/числа), чтобы не влиять друг на друга.
3. Если оценки сильно разошлись — самый высокий и самый низкий объясняют почему. Часто всплывает важный нюанс.
4. Переоценивают, пока не придут к консенсусу.

Ценность не в самих числах, а в обсуждении: расхождение оценок вскрывает разное понимание задачи до начала работы.

Как калибровать оценки

Чтобы story points были осмысленными, команде нужен якорь — эталонная задача. Выберите вместе хорошо понятную задачу и назначьте ей, скажем, 3. Дальше всё оценивается относительно неё. Со временем команда «срабатывается», и оценки становятся стабильными.

Типичные ошибки

• Конвертируют в часы. «1 поинт = 4 часа» убивает весь смысл относительной оценки.
• Делают KPI. Как только за story points начинают «спрашивать», команда раздувает оценки.
• Сравнивают команды. Поинты у каждой команды свои — сравнивать velocity между командами нельзя.
• Оценивает один человек. Сила в командной оценке, а не в мнении тимлида.

Оценки удобно держать рядом с задачами и таймлайном — например, в TeamVector, где бэклог, доски и Гант собраны в одном месте. Подробнее про методы оценки — в материале оценка задач в разработке.

Частые вопросы