Story Points (Очки Истории) — это единица измерения сложности, трудозатрат и неопределенности для оценки задач (User Stories) в Product Backlog. В отличие от часов, Story Points отражают относительную оценку: задача в 8 очков не в два раза длиннее, чем задача в 4 очка, а в два раза сложнее.
Разработчики используют Story Points, чтобы быстро и коллективно оценить работу, сравнивая новую задачу с уже завершенной базовой задачей (Baseline). Эта метрика используется для прогнозирования того, сколько работы команда может выполнить за Спринт, что выражается в Velocity.
Что Включает Оценка в Story Points?
- Сложность (Complexity): Техническая трудность реализации, количество затронутых систем.
- Объем Работы (Effort): Чистые трудозатраты (время кодирования, тестирования).
- Неопределенность/Риск (Uncertainty/Risk): Насколько команда уверена, что знает, как это сделать. Если риск высокий, оценка выше.
- Связи: Необходимость координации с другими командами или работы с устаревшим кодом.
| Характеристика | Story Points (Очки Истории) | Часы (Hours) |
| Единица Измерения | Сложность и Риск (относительная оценка). | Время (абсолютная оценка). |
| Что учитывает | Технический риск, сложность, объем. | Только объем работы, без учета внешних факторов. |
| Конвертируемость | Не конвертируется в часы. | Прямо конвертируется (что приводит к давлению). |
| Фокус Команды | На обсуждении сложности и прогнозировании. | На выполнении работы в срок (часто приводит к спешке). |
| Кто Оценивает | Разработчики коллективно. | Часто один человек (эксперт) или менеджер. |
Таким образом, использование Story Points — это не просто прихоть Agile, а механизм, который стимулирует коллективное владение оценкой и улучшает Прозрачность рисков. Когда команда использует Planning Poker или другой метод оценки, каждый член команды вынужден обдумывать все аспекты задачи — от сложности до тестирования. Следовательно, Story Points помогают команде выявить неясности в User Story еще до начала Спринта.
Важно помнить, что Story Points — это всего лишь инструмент прогнозирования, и они не должны использоваться для наказания или сравнения эффективности отдельных разработчиков. Если Velocity команды нестабильна, проблема, скорее всего, не в Story Points, а в процессе (например, плохой Definition of Done или частые прерывания). Поэтому Story Points должны служить команде, а не наоборот.
ГЛАВНЫЙ ВЫВОД (РЕЗЮМЕ): Story Points — это инструмент для оценки СЛОЖНОСТИ, а не ЧАСОВ. Они позволяют команде прогнозировать работу, основываясь на относительном сравнении, а не на точном времени. Использование часов часто приводит к стрессу и неточностям, тогда как Story Points стимулируют командное обсуждение и прозрачность рисков.
Часто задаваемые вопросы (FAQ)
Ряд Фибоначчи используется для отражения растущей неопределенности. Чем больше задача (например, 20 вместо 5), тем сложнее ее оценить точно. Разрывы в ряду (между 8 и 13, а не 9, 10, 11…) заставляют команду остановиться и обсудить, действительно ли задача настолько велика и неопределенна, и, возможно, разбить ее (сделать Refinement).
Базовая История — это задача, которая была выполнена в прошлом, и ее оценка (например, 3 Story Points) стала эталоном для команды. Новая задача всегда сравнивается с этой базой: “Эта задача в два раза сложнее, чем наша Базовая История? Значит, это 6 (или 5) очков.” Это обеспечивает относительность оценки.
Нет. Оценка дается во время Планирования Спринта или Refinement и остается фиксированной на время Спринта. Если команда обнаруживает, что задача оказалась гораздо сложнее, чем казалось, это должно быть обсуждено на Ретроспективе для улучшения будущих оценок, но не для изменения текущей Velocity.
Ответственность за оценку всегда лежит на Команде Разработки коллективно, а не на Product Owner’е или Scrum Master’е. Это обеспечивает владение командой своим планом и делает оценку более точной, так как учитываются все технические аспекты.
Это антипаттерн. Product Owner должен использовать Velocity (среднее количество Story Points, которое команда выполняет за Спринт) для прогнозирования сроков доставки, а не пытаться конвертировать Story Points в часы. Story Points отражают сложность, а не время, и их конвертация подрывает доверие и фокус команды.