Это инструмент, который легально снимает с команды ответственность за сроки.

Вот как это работает. Разработчик оценивает смену цвета кнопки в 13 поинтов. Менеджер кивает — звучит весомо. Через две недели задача не готова. «Мы не угадали сложность, velocity упала». Никто не виноват, система работает как надо. Только продукт снова опаздывает, а контракт под угрозой.

Проблема не в команде. Проблема в том, что Story Points создают иллюзию измерения там, где измерения нет. Траут и Райс описали этот механизм точно: восприятие важнее реальности. Команда не врет напрямую — она управляет восприятием менеджера. «8 поинтов» звучит как цифра. По факту это «мы не берем обязательств по срокам», упакованное в методологию.

Разработчики выстроили систему, в которой невозможно ошибиться, потому что в ней нечего проверить. Часы проверяются — дедлайн либо соблюден, либо нет. Поинты — нет. Velocity меняется, спринты пересчитываются, ретроспективы объясняют все. Это не Agile. Это бюрократия без ответственности.

Что я делаю на практике:  1. Требую двойную оценку по ключевым задачам: поинты для команды, часы для разговора с бизнесом 2. Раз в квартал фиксирую расхождение плановой и фактической velocity — не для наказания, а чтобы видеть, насколько система вообще работает 3. Когда команда говорит «это непредсказуемо» — прошу разбить задачу на части, пока каждая часть не станет конкретной. Непредсказуемость — это не свойство задачи, это сигнал, что задача не понята

Менеджер, который принял Story Points как единственный язык разговора о сроках, не управляет планированием. Он управляет иллюзией планирования. Разница становится очевидной только в момент, когда срывается дедлайн, который «никто не мог предсказать».