Storypoints - один из широкотиражируемых, но мало-полезных инструментов в IT.

Что в них полезного?

"Они" заявляют, что это снимает стресс с разработчика по поводу установки конкретных сроков. Это комплексная оценка, включающая в себя время, сложность, неопределенность. При этом мы можем использовать их при планировании спринтов, считая капасити/велосити на этих магических цифрах. Часто предлагают использовать ряд Фибонначи и если задача больше N сторипоинтов, то декомпозировать ее. Это то, как делал я многие годы своей практики, в том числе.

Но что с ними не так по моему мнению?

Абсолютное большинство людей пытаются явным или не явным привязать их ко времени, что в корне не верно. Это комплексная оценка и время лишь один из ингридиентов. И даже если вы утверждаете, что вы так не делаете, то я на 90% уверен, что вы лукавите. Вспомните фразы вроде "ну 5 сторипоинтов, это где-то 2 дня" или вашу попытку уместить в 2-х недельный спринт определенное кол-во сторипоинтов. Вы пытаетесь свести время (спринт) и комплексную оценку (время, сложность, неопределенность) друг с другом. Это как пытаться вставить кассету от сеги в денди и ждать, что игра заработает (привет детям 80-90-х).

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

В конце-концов, бизнес интересует "Когда", а не "Сколько сторипоинтов".

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

3 сторипоинта в одной команде - не тоже самое, что 3 сторипоинта в другой команде. Как вы собираетесь в таких условиях планировать деятельность проекта/продукта мне крайне не ясно. Да, бывают уникумы, у которых все настолько плохо, что даже оперируя сторипоинтами они могут сделать лучше, но если вы от них откажетесь правильным образом, то вам станет лучше с бОльшим эффектом.

Дополнительный вред для команд разработки - помните, что сторипоинты у всех разные?

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

А что тогда использовать?

Дни или часы - главное, временные периоды. Всякие T-shorts сродни сторипоинтам.

Доп бонус для начинающих aka историческая справка

Уже традиционно сторипоинты связывают со скрамом, хотя впервые они появились в Extreme Programming (XP).

Рона Джеффриса, одного из основателей XP и подписанта Agile-манифеста, идея story points появилась в области XP в конце 1990-х годов.

А в Scrum они до сих пор не входят (тут меня можно поправить, но не нашел их при подготовке поста.)

И вишенка на торте - со мной согласен создатель сторипоинтов 😁

Мой телеграмм канал @knstntnpk