"Если я изобрел стори поинты, я извиняюсь за это"
Написал создатель стори поинтов Рон Джеффрис у себя в блоге. Рон изначально изобрел модель "идеального дня" — это реальный день, когда тебя не отвлекают на созвоны и параллельные задачи. Задачи оценивались в идеальных днях, умноженных на коэффициент три, чтобы учесть время на созвоны и прерывания в работе. Позже идеальные дни Рон переименовал в стори поинты, и началось.

Ниже я кратко привожу аргументы Рона. Не могу сказать, что согласен с ним полностью. Не принимайте это как истину в последней инстанции, это — лишь мнение человека. Пусть и создателя поинтов.

Сравнить команды
Разные команды могут оценить одну и ту же задачу по-разному. Это не означает, что одна команда слабее другой. Стори поинты родились из концепции "идеального дня" — без созвонов и прерываний.

Сравнивать команды на основе их оценок в стори поинтах нельзя, потому что:
- У разных команд отличается количество созвонов и прерываний
- Команды работают с разным количеством технического долга и легаси

Для сравнения команд стори поинты не подходят.

Сравнить сроки
Если вы оценили задачу в стори поинтах, нужно в итоге сравнить реальные сроки выполнения и изначальную оценку, ведь так? Если оценка и реальность разошлись, нужно провести ретроспективу, понять причины и начать оценивать лучше?

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

Так что стори поинты и тут бесполезны.

Давить на команду
В красной книге SCRUM сказано, что количество стори поинтов, которые команда берет в спринт, должно постоянно расти от спринта к спринту. Такой подход приведет к майндсету "количество важнее, чем качество" — разработка начнет срезать углы и копить технический долг, а QA начнут пропускать баги.

Это как постоянно сжимать пружину в погоне за количеством. Рано или поздно, пружина разожмется и, может быть, попадет кому-то в лоб.

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

Стори поинты хороши для давления на команду, но само давление — плохая идея.

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

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

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