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

1. Как перевести стори поинты в часы?

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

Для начала стоит отметить, что стори поинты чаще всего используются в Скрам-командах. Для них главный временной ориентир — это Спринт. Когда Владелец Продукта и Команда разработки договариваются сделать какую-либо работу, они планируют её на ближайший спринт. В таком случае Владельцу Продукта (человеку, которому обычно чаще всего интересны сроки) не так важно, сколько времени будет делаться конкретная задача. Ему важно, чтобы Цель Спринта была достигнута. В этой системе координат оценка задач в часах перестаёт быть актуальной.

С другой стороны участники команды могут воспринимать оценку во времени как дедлайны. Для людей это часто повод откладывать работу на последний момент. Таким образом, задача, которая могла бы быть сделана за пару часов, делается целый рабочий день, потому что изначально на неё было заложено столько времени.

Если вы попробуете связать стори поинты и часы, то поймёте, что время — это неоднозначный показатель для сравнительной оценки. Такая конвертация не принесёт пользу ни Команде, ни Владельцу Продукта.

2. Зачем использовать для оценки задачи число?

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

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

3. Нужно ли переоценивать задачу, если она переходит в следующий спринт?

На этот вопрос не существует однозначного ответа. Для начала стоит понять, почему команда хочет переоценить задачу. Она оказалась больше предполагаемой? Вы изначально неверно спланировали спринт?

Если задача оказалась больше, чем предполагалось, но при этом вы понимаете, что сможете завершить её в новом спринте, то переоценивать её нет смысла. Вы уже провели какую-то работу по этой задаче, вам известны риски. Нет ничего страшного в ошибочной оценке — это лишь повод обсудить на ретроспективе, почему так вышло. С другой стороны переоценка даёт прозрачность понимания, сколько работы будет выполнено за спринт. При подсчёте скорости за спринт вы получаете верное значение. Однако остается открытым вопрос о том, что делать со скоростью в предыдущем спринте: засчитывать или нет стори поинты за сделанную часть работы над задачей.

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

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

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

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

4. Равны ли друг другу стори поинты двух команд?

Если мы говорим о командах, работающих над одним продуктом (например, в LeSS), то да, равны. У таких команд один бэклог продукта, соответственно, любая из команд может самостоятельно выполнить любой элемент из этого бэклога. При оценке задач участвуют все члены команд, что позволяет им находиться в едином информационном поле.

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

5. Можно ли оценивать эффективность команды с помощью стори поинтов?

Давайте представим, что мы собрали команду и начали работу над новым продуктом. Со временем стало ясно, что средняя скорость команды за спринт — 20 стори поинтов.

Тут к команде приходит какой-то большой начальник и говорит, что было бы неплохо начать измерять эффективность команды через стори поинты. Проходит несколько месяцев, команда уже лучше начала разбираться в продукте, выпускает все больше задач для конечных пользователей, прибыль от продукта растет, все счастливы и довольны, кроме того самого начальника… Оказалось, что дело в том, что количество стори поинтов за спринт сильно не прибавилось, всего-то на 3-5 значений выросла скорость. Начальник снова приходит к команде и говорит, что они молодцы, но вот по значениям стори поинтов все не так хорошо, особенно по сравнению вон с той командой. В общем-то из команды никто толком и не понял почему ими недовольны, только вот стали на всякий случай давать побольше оценку задачам, чтобы у начальника не возникало ощущения, что они ничего не делают и никак не развиваются.

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

Со временем команда начинает все быстрее приносить ценность. Но измерять эффективность команды в стори поинтах довольно неэффективно.

Почитать о том как измерять эффективность можно здесь

6. Можно ли использовать стори поинты не только в скрам командах?

С этим вопросом сталкиваются множество команд, которые, например, не используют итерации. Кажется, что процесс уже визуализирован, и есть желание внедрять улучшения. В таком случае команды пытаются начать с процесса оценки и перейти от старых добрых человеко часов к модным и зарекомендовавшим себя стори поинтам. И тут же возникают непредвиденные трудности. Дело в том, что не все учитывают то, что в разных процессах ограничен разный ресурс. Для Скрам-команд главное ограничение — это время. У них есть Спринт, который может длиться максимум 4 недели. С команды это снимает необходимость определять время выполнения каждой задачи, так как они всегда должны стремиться к тому, чтобы задача была сделана в срок Спринта. Для не Скрам-команд вопрос сроков всё ещё остаётся легитимным, и зачастую Команде всё же приходится на них отвечать. В таком случае ответ в стори поинтах не может удовлетворить интересы менеджмента и не поможет в дальнейшем планировании.

Для не Скрам-команд оценка в стори поинтах не может быть чем-то запрещённым. Если им удобно оглядываться на критерии объёма, сложности и рисков, то они могут оценивать так задачи. Но, к сожалению, для таких команд стори поинты — это не лучшая практика. Стори поинты — это максимально полезный инструмент для команд, которые живут в рамках итераций.

7. Нужно ли учитывать при оценке задачи скиллы ее исполнителя?

Отличительной особенностью стори поинтов как раз и является то, что задачи оцениваются относительно друг друга. Совершенно не имеет значения, кто именно возьмётся за работу над задачей — новичок или профи. Представьте, что вам нужно пробежать 1км. Да, каждый человек пробежит его за разное время, но это будет по-прежнему 1км. Оценка в стори поинтах никак не связана с уникальными способностями человека, который работает над задачей. С оценкой должны быть согласны все члены команды.

Если мы оцениваем задачу по способностям её исполнителя, то мы невольно возвращаемся к оценке задач по времени, что не совсем продуктивно, как мы выяснили в первом вопросе.

Авторы статьи: Карамнова Виктория, Кочарян Эмилия