Абсолютно згоден. Чомусь СП намагаються використати будь-де, будь-як. Тому і результат може бути неочікуваний.

Дякую за відгук, Oleh Lukutin! Згоден, що з часом у команди з"являється стабільний рівень Velocity. Але час, як-то кажуть, не стоїть на місці, прогрес рухається вперед, з«являються нові інструменти типу «АІ», тобто щось, що однозначно впливає на цю саму Швидкість команди в більшу/кращу сторону, але цифри не показують це. Гадаю, ви можете самі спостерігати цей феномен.
І так, абсолютно з годен, що краще дивитися на Цінність, яка надається користувачам, а також на метрики навколо неї, але чомусь SP залишаються незмінним атрибутом в багатьох проектах. І дуже часто — єдиним показником ефективності. Нажаль.

Дякую за відгук, Oleksandr Tsapenko!
Я чомусь підозрюю, що SP змінюється самою командою з часом, і це несвідомо. Буду радий, якщо би ви подивилися в своїй команді на задачі пару років тому і зараз і порівняли їх, ну і підтвердили б мою підозру або спростували її. Я таке збираю у власну «копілочку». До речі, тема для ретороспективи непогана, не знаходите?
А стосовно зміни шкали вимірювання, то це теж до «а що ви хочете досягти цим»? Гадаю, різні цілі можуть дати різні відповіді.

Дякую за відгук, Тетяна Гамайда! Особливо про «диво людину». Так, я пишу сам.
Про ваше питання, якщо я правильно вас зрозумів, що це про «методики оцінювання», то потрібно дивитися на те, яку проблему ми хочемо вирішити. Навіть ці «неправильні» SP непогано працюють на проміжку квартала: по спринтам можемо відставати, але ближче до закінчення квартала наздоганяємо. Так само можна використовувати просто кількість задач, але це для сталої команди, яка працює разом хоча б пів-року. Знову ж такі, яка ціль — такий і інструмент має бути. В цьому прикладі, що я навів, мова про цінність взагалі не йде, просто про «закрити те, на що комітилися на початку». Зазвичай, все починає змінюватися вже впродовж першого спринта, після другого вже остаточно бачимо, що можна щось інше, більш корисне, робити, але «потяг вже пішов», зупинити дуже важко. Як з цим нам може допомогти оцінювання задач взагалі?

Дякую за відгук, Andre!
Хотілось би ще відмітити, що SP були вигадані для оцінки саме командних задач, що звуться User Story, від цього і назва Story Point, тобто задач, над якою працює декілька людей/ролей одночасно. В ідеалі, звісно, всі Розробники. Тобто, одна задача — багато розробників. Тут про оцінку в часі складно розмовляти, тому СП більш вигідніше. Але в більшості випадків у нас є інший флоу: одна задача — одна людина. Про які Відносні SP тут можна казати взагалі? Тут людина дає оцінку в часі, і для неї це теж Відносна річ: ця задача складніше/довша/більша відносно іншої, але це все відбувається в часі. А потім цей час трансформується в SP: 1 — 2 дні роботи над задачею = 1 SP. А мало б бути навпаки, спочатку SP без прив"язки до часу, а потім дивимося, скільки це зайняло днів.
Буду радий почути вашу думку

Дякуюза відгук, Kateryna Khyzhniak! Продовження готую, чекайте ;)

Я теж за те, щоб або правильно використовувати, або не використовувати взагалі.
Дякую за відгук, Andrii Bezuglyi

Дякую, Станіславе, за відгук! Зі SP не все так просто, як хотілось би. До речі, це і сам їх винахідник Рон Джеффріс (Ron Jeffries) признає. Останні три роки в різних командах командах слідкую за кількістю закритих задач (throughtput) (це той самий noestimatе), то хочу зазначити, що це так само працює не гірше за SP.
Тут більше потрібно подумати, яку саме проблему ви хочете вирішити естімацією. І від цього вже відштовхуватися при виборі одиниць виміру.