Story Points в Scrum: оценка задач в Agile, Стори Поинты

Многие заказчики требуют точной оценки задач и сроков реализации проекта, но это не всегда возможно.

Да и в чем нужно оценивать задачи или процессы: в часах, днях, неделях, месяцах, деньгах или в количестве занятых сотрудников? Ответ частично дал подход, предложенный Роном Джеффрисом.

Ниже расскажем о том, что такое сторипоинты, как с их помощью правильно оценивать задачи, какие методы оценки используются чаще всего и рассмотрим плюсы и минусы относительных оценок.

Что такое Story Points

Story Points (сторипоинты) — это относительная единица измерения усилий, которую команды, работающие по принципам Agile (особенно в метрологиях Scrum и Kanban), используют для оценки сложности и объема задач.

Дословный перевод на русский звучит как «очки истории», но фразу не переводят, так как в ней кроется отсылка к термину User Story (история пользователя). Юзерстори – это краткое описание конкретной полезной функции с точки зрения пользователя. Переводить story здесь бессмысленно, это своего рода единица планирования. Для команды разработчиков – это задачи глобального уровня, которые можно детализировать на множество мелких составляющих и включить в реализацию на предстоящую итерацию.

В отличие от привычных оценок объема работы в часах или днях, сторипойнты не привязаны к конкретному времени. Они отражают относительный вес задачи по сравнению с другими: насколько она сложнее или проще эталонной задачи.

В story points измеряют задачи в списках User Story и в бэклоге, в них также можно измерять производительность команды (velocity).

Краткая запись – SP. Примеры пользовательских историй и оценок:

Как пользователь я хочу зарегистрироваться по email и паролю — 5 SP (5 story points).
Как авторизованный пользователь я хочу просмотреть свой профиль — 2 SP (2 story points).
Как неавторизованный покупатель я хочу добавить товар в корзину — 3 SP (3 story points).
Как авторизованный покупатель я хочу удалить товар из корзины — 1 SP (1 story point).
Как неавторизованный клиент я хочу искать товары по ключевому слову — 8 SP (8 story points) и т.д.

Автор идеи — Рон Джеффрис, один из основателей подхода Extreme Programming (XP) и подписант Манифеста Agile. Именно он в конце 1990-х ввел концепцию сторипоинтов в практику XP-команд.

Сам Рон позже неоднократно шутил и признавался:

«I like to say that I may have invented story points, and if I did, I’m sorry now»

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

Он объяснял, что идея возникла как способ отойти от оценки в часах и днях, чтобы команды могли сравнивать размер задач в относительных единицах, не попадая под давление «точных сроков» от менеджмента.

Зачем нужны стори поинты в проектах и планировании

Story Points позволяют командам оценивать сложность задач по условной шкале. Если оценивать задачи в часах или днях, то точность получается слишком низкой. Иногда для этих целей также используются человеко-часы, но и они не добавляют точности. В реальности любая задача может внезапно разрастись, и тогда общее время реализации проекта может смещаться на большие сроки.

В отличие от традиционных оценок в часах или днях, оценка в сторипоинтах фокусируются не на времени выполнения, а на общей сложности работы. В этом случае учитываются:

объем задачи,
ее техническая сложность,
уровень неопределенности,
возможные риски,
имеющиеся знания / компетенции команды в данной области.

Этот метод оценки делает планы более объективными и гибкими, помогая избежать многих типичных ошибок.

Благодаря Story Points команда может сравнивать задачи между собой по относительной сложности, а не по абсолютному времени.

Обычно Story Points используют в рамках Scrum и Agile, где требования часто меняются, а объем работы сложно предсказать заранее. Такой подход помогает сделать планирование более понятным и одновременно гибким.

Преимущества Story Points

Оценка с помощью стори поинтов обеспечивает ряд важных преимуществ, которые помогают команде лучше планировать свою работу и нагрузку.

Если внедрить story points, то вы сможете объективнее учитывать сложность, неопределенность и риски по наиболее важным задачам. Планирование становится точнее.
С помощью story points команда приходит к относительным размерам задач, сравнивая их между собой – это легче и понятнее.
Оценка в часах – это всегда определенные обязательства и давление со стороны заказчиков, тогда как при использовании story points команда сглаживает углы. Обязательства получаются более гибкими и обтекаемыми, и вопрос относительно того, сколько времени займет реализация, уже не стоит так остро.
При планировании спринта каждый член команды лучше понимает ценность каждой задачи и ее значение для продукта.
При достаточном накопленном опыте значение story points будет становиться все точнее и точнее. Со временем команду будет лучше понимать, какое количество story points она стабильно выполняет за один спринт.
Оценки в стори поинтах упрощают сравнение и приоритизацию задач. Когда все элементы бэклога оценены в одной шкале, Product Owner (владелец продукта) может объективнее принимать решения, балансируя между ценностью и сложностью.

Недостатки Story Points

Несмотря на очевидные плюсы, использование Story Points имеет и свои ограничения.

Главный недостаток — субъективность оценок. Разные команды и даже разные люди внутри одной команды могут по-разному воспринимать одну и ту же сложность, особенно на начальных этапах работы, что приводит к неточностям. По крайней мере до того момента, пока команда не выработает общее понимание единой шкалы.
Еще один минус — сложность объяснения стори поинтов стейкхолдерам и заказчикам, которые привыкли мыслить в привычных категориях «часы», «дни» или «месяцы». Поэтому неизбежно возникает вопрос: «Что значит 40 Story Points и когда это будет готово?»
Story Points также требуют времени и определенных усилий на регулярную калибровку оценок – для проведения покер-планирования, ретроспектив и т.п. Без этого точность быстро падает.
В некоторых проектах с очень предсказуемыми задачами и стабильными требованиями использование сторипоинтов может быть избыточным. В таких случаях более наглядная для заказчиков оценка в часах или днях может оказаться эффективнее.
Стори поинты не защищают от переоценки или недооценки сроков выполнения задач, если команда игнорирует историю предыдущих спринтов или использует их некорректно.
Чтобы зафиксировать сроки в договорах с заказчиками, многие команды начинают пересчитывать сторипоинты в некое количество часов, что сводит на нет весь их принцип работы.

Основные методы оценки задач в Story Points

Ниже расскажем об основных методах и подходах по оценке в story points.

1. Покер планирования / оценка по шкале Фибоначчи

Это самый известный и распространенный метод оценки на основе консенсуса.

Принцип работы:

Каждый член команды получает набор карт, физических или виртуальных, со значениями из модифицированной последовательности Фибоначчи, являющейся математической интерпретацией «Золотого сечения». Основная идея – быстрый рост значений.

Почти всегда используются значения: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 или ∞.

Ведущий, в норме это скрам мастер или владелец продукта, читает описание задачи.

Команда кратко ее обсуждает. Затем все показывают свои карты, желательно одновременно. Если оценки сильно расходятся, обсуждают каждое значение Story Points – почему кто-то поставил одну оценку, а кто-то другую, уточняют детали и повторяют раунд до достижения консенсуса или близких значений.

Плюсы:

Стимулирует глубокое обсуждение и выявление скрытых рисков, неопределенностей и разных взглядов.
Уменьшает влияние авторитетных мнений (якорей).
Повышает вовлеченность всей команды и точность оценки за счет коллективного обсуждения.
Хорошо подходит для максимально точного планирования спринта.

Минусы:

Может занимать массу времени, особенно при большом бэклоге или если членов команды много.
Новичкам нужно несколько циклов торгов на калибровку понимания шкалы.
Если обсуждения не контролировать, то сессия может затянуться еще дольше.

Практический пример:

Команда оценивает задачу «Реализовать авторизацию через ЕСИА». Один разработчик ставит 5 (для него это знакомая технология), другой — 13 (он закладывает время на изучение, регистрацию и другие шаги). После обсуждения команда приходит к 8 SP.

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

2. Оценка по размеру футболок

Простой инструмент относительной оценки, используемый для грубой приблизительной оценки.

Принцип работы:

Задачи оцениваются категориями размеров футболок: XS, S, M, L, XL, XXL, иногда добавляют XXXL как аналог бесконечности.

Команда обсуждает задачу и присваивает ей размер по принципу, насколько она больше/меньше других. Если задача не влезет в выбранный размер, ее двигают в следующий, и так пока размер всех не устроит.

Позже размеры можно конвертировать для использования SP, например: XS – это один стори поинт, S – два или три, M – 5, L – 8 или 13 и т.д.

Плюсы:

Очень простой и интуитивно понятный подход, что помогает быстрее перейти к оценке без длительного обсуждения сложных механик начисления, как в случае с последовательностью Фибоначчи.
Мероприятие проводится максимально быстро, что особенно важно на ранних стадиях планирования проекта, например при составлении дорожной карты или оценке эпиков.
Легко объяснять стейкхолдерам, не знакомых с механизмом Storypoint.

Минусы:

Низкая точность из-за большого шага «размера футболок».
Труднее планировать спринты с точным объемом работы.
Разные люди могут по-разному понимать, что такое M или L.

Пример:

При грубой оценке бэклога на квартал команда относит простую правку UI к S, новую интеграцию с внешним сервисом — к L, а полный рефакторинг модуля — к XL.

3. Система корзин / Bucket Estimate

Быстрый метод группировки задач по категориям сложности.

Принцип работы:

На доске или в профильном сервисе создаются «ведра» или «корзины» (buckets) с заранее определенными значениями Story Points. Например, если вы используете систему управления проектами, то на роль корзин подойдут колонки в отдельной канбан-доске или категории для задач.

Ведущий берет задачу, кратко описывает ее, и команда коллективно решает, в какую корзину ее поместить. Задачи сортируются по относительному размеру. При необходимости их можно перегруппировывать.

Плюсы:

Значительно быстрее покер-планирования при большом количестве задач.
Методика отлично показывает себя с крупными бэклогами.
Визуально демонстрируются одновременно и относительные размеры задач, и группы, с которыми они соотносятся. Когда задачи концентрируются в одной корзине, сразу становится видно, если какая-то из них была оценена неправильно.

Минусы:

Здесь практически нет глубоких обсуждений или торгов по отдельным задачам.
Измерение может быть менее точным, если команда не обсуждает расхождения во мнениях.
Требует дополнительной работы для подготовки шкалы корзин.

Пример:

Команда быстро распределяет 30 задач по корзинам: простые баг-фиксы уходят в 1–2, средние фичи — в 5–8, а сложные интеграции с высокой неопределенностью — в 13–20.

Оценка по эталону – «38 попугаев»

Суть метода — выбрать одну эталонную задачу, того самого «попугая», присвоить ей минимальное значение, один сторипоинт. А все остальные задачи оценивать относительно нее – по принципу «во сколько раз она сложнее/больше эталона».

Принцип работы:

Команда выбирает самую простую, хорошо понятную и уже выполненную (или типичную) задачу из своего прошлого опыта. Ее объявляют эталоном «попугая». Технически это не обязательно может быть 1 SP, вполне допускается 2 SP, чтобы можно было оценить более мелкие задачи.

Теперь каждая задача, подлежащая оценке, сравнивается с эталоном.

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

Плюсы:

Очень простой и понятный подход – как для новичков, так и для профи.
Технически эталон может быть любым и его необязательно сравнивать с попугаем. В исходном варианте упор сделан на относительность и на элемент игры, ведь все знают, что 38 попугаев – это один питон.
Эталон снижает субъективность: все сравнивают объем задач с одним и тем же «попугаем», а не со своими личными ощущениями.
Результат легко объяснить стейкхолдерам. Главное – не забыть конвертировать попугая в реальную задачу, которая знакома не только вам, но и представителю заказчика.
У команды появляется своя собственная внутренняя шкала для измерения производительности.

Минусы:

Подход довольно грубый для мелких задач — сложно отличить 1 SP от 2 SP, если эталон выбран неидеально.
Со временем эталон может «устаревать»: когда команда становится быстрее или меняется стек технологий, старый «попугай» перестает быть хорошей точкой отсчета.
Менее точен при оценке задач разных по типу. Например, одна — чистый код, другая — исследование + интеграция.
Требует периодической калибровки эталона. Обычно это делается на ретроспективах.
Для расчета показателя velocity все равно нужно переводить оценки в числа, поэтому количество «попугаев» редко используется в чистом виде.

Пример использования:

Эталоном выбрана задача «Добавить кнопку “Поделиться” в интерфейс» — это один «попугай». Тогда задача с добавлением валидации формы» —1,5 попугая, реализация авторизации через соцсети — 4 попугая. И т.д.

Эффективна ли оценка задач в Story Points в часах?

Если коротко, то нет. Основная цель сторипонтов – как раз отойти от часов и сделать оценку относительной. Попытка жестко привязать ее к часам, например, 1 SP = 8 часов или 5 SP = 2 рабочих дня, сводит на нет почти все преимущества сторипоинтов.

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

Отдельно про актуализацию размерности задач и про аналитику

После того как ваша команда проставила оценки, работа системы сторипоинтов не заканчивается. Чтобы значения SP стали максимально приближенными к реальности, нужно своевременно их актуализировать по мере реализации проекта и отдельных задач.

Что еще может повысить пользу методики:

Как можно чаще сравнивайте план/факт. Так вы сможете оценить, насколько ваши ожидания оказались близки к реальной картине.
Ведите статистику своей производительности. Так оценка сможет стать точнее.
Регулярно пересматривайте свой эталон. Дело в том, что со временем, когда участники команды притираются друг к другу и набивают руку, усилия по реализации минимальной задачи могут сильно сократиться. Соответственно, условные оценки новых задач могут потерять свою актуальность.
Чтобы эталон долгое время оставался актуальным, старайтесь выбирать частую рутинную, практически повседневную задачу, которая встречается в большинстве ваших проектов.

Для повышения надежности старайтесь комбинировать подход Story Points с другими. Как минимум, пробуйте разные форматы расчета и оценки задач из предложенного списка выше, так вы сможете найти тот формат, который будет максимально соответствовать потребностям вашей команды.

Чтобы вести учет SP по задачам, можно использовать механизм дополнительных полей в задачах. В Projecto дополнительные поля точно есть!