Обычно, да, по крайней мере, там, где я сталкиваюсь

В общем, если вернутся к контексту использования Stopy Points для декомпозированных задач
в рамках одной команды. Когда мы элементы декомпозиции оцениваем отдельно по SP а потом складываем SP и пытаемся запихнуть в Спринт, натягивая на линейку Capacity

Мы по факту сравниваем со временем - успеем или нет.
Но при этом мы вообще не понимаем как матчится SP на время.

Как обычно это делается в метрологии?
1. Берем измеряемые элементы и смотрим как они на шакле себя позицианируют. Например 1SP на время.
2. Получаем распределение
3. Берем наиболее вероятное событие из распределения
4. Фиксируем измерение (округляя) все остальные к наиболее вероятному.

Но тут есть свои но
1. Шкала времени - не формирует нормально распределение, по этому наиболее вероятное событие определяем процентилем
2. Отдельно 1SP нет вообще смысла рассматривать. Т.к. мы не можем поставить чистый эксперемент по решению задач с 1SP, 2SP, 3SP - и как-то выработать общую шкалу по времени.

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

Да, у нас есть вариативность.
И тут мы можем сказать, а давайте пойдем путем великого Уолтера Шухарта, и придумаем пределы для нашего графика Velocity и в рамках этих пределов будем как-то жить по средней.

Забывая оглядываться на то, что с изменением общей среды, меняются и пределы.
Ну ок, давайте ориентироваться на среднюю плавающую, и будем адаптировать Velocity под нее.

Еще одну проблему порождаем - а как считать тогда среднюю плавающую, это ж сколько спринтов надо для нормального расчета?

И это при том, что мы даже осознаем что шкала SP вообще не матчится ровненько на Время.
Т.е. мы умножаем одну ошибку на другую, и хотим при этом получать ровные срезы.

Вопрос - зачем такие сложности?
Scrum - же отлично сказано - одна цель на один спринт. Нафига нам вообще там SP?
По сути - старайся успеть за спринт сделать одну задачу. Мелочь, то же можно но не так важно

Тогда длину спринта надо менять нет?)))

There is no silver bullet!)

Это тонкий вопрос. Длину спринта выбирают из реальных возможностей, по идее.
Т.е. необходимо изначально узнать, а какие сейчас вообще технические возможности есть?
Так же для определения длины спринта нужно учесть частоту и сложность зависимых задач (по сути влияние) и если есть потери времени на буферных состояниях, то учесть, на сколько можно сократить время уменьшив очередь.

Конечно, при техническом прорыве, типа внедрения новых инженерных практик существенно повлиявших на время, тоже можно менять длину спринта.

Тогда длину спринта надо менять нет?)))

There is no silver bullet!)

Там хорошо описывается сбалансированный расчёт размера пакета для оптимизации обслуживания!

Если вы про увеличение спринта, то это обчно вызывает изжогу и покраснение лица мастера который выстравивает процесс, часто такое принимают на свой счет как некомпитентность

Вангую через месяц, опять вернемся к этой теме. Прям какая-то напасть с любителями складывать SP :)

1 - й закрытый вопрос, порождает системное размышление и вариации исходя из возможностей
2 - й открытый вопрос, порождает открытое размышление исходя из предположений как бы можно было.

По этому, чаще всего ответить на второй вопрос - это очень сложная задача.
А вот на первый гораздо проще.

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

Это позволяет имплементору лучше сориентироваться и быстрее дать ответ.

На второй вопрос ответить оч просто: когда закончится срок проекта. Смотрим определение проекта.

Где смотреть?
1. ISO/IEC 15939:2007
2. ISO/IEC 2382-20:1990
3. ISO/IEC 26514
4. PMBook
5. ....
???

А что так можно было?

Где угодно. У проекта есть срок.