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

Шта-то я потерялся. Это имеет отношение к Agile, Scrum, Lean, Kanban, XP? ;)

Шта-то я потерялся. Это имеет отношение к Agile, Scrum, Lean, Kanban, XP? ;)

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

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

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

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

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

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

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

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

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

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

много слов но нет ответов на поставленные вопросы
1. почему нельзя складывать сп (и не будет, потому что сп в конечном итоге это время, а время можно складывать)
2. зачем нужны сп если нельзя складывать
можно сп заменить на оценку количества мешков под картошку на даче или на оценку времени на убор разных полей картошки и говорить что они не матчатся потому что оценка выполняется на глаз и с погрешностью. но мешки можно складывать. как и время. нужно просто понимать что это грубый прогноз и не кричать "я же говорил!" если он не сойдется с реальностью

А если посмотреть на SP как на меру трудоемкости? Условно - самолет состоит из сотни узлов. Сделать, испытать и установить каждый узел - оценка в столько-то SP трудоемкости. Тогда если сложить эти SP, то по идее можно сравнительно оценить (но не определить точно и абсолютно) трудоемкость создани самолета?
не?

Правда такая оценка будет иметь смысл, если бы мы сравнивали разные самолеты между собой, наверно. То есть в одном классе задач.

много слов но нет ответов на поставленные вопросы
1. почему нельзя складывать сп (и не будет, потому что сп в конечном итоге это время, а время можно складывать)
2. зачем нужны сп если нельзя складывать
можно сп заменить на оценку количества мешков под картошку на даче или на оценку времени на убор разных полей картошки и говорить что они не матчатся потому что оценка выполняется на глаз и с погрешностью. но мешки можно складывать. как и время. нужно просто понимать что это грубый прогноз и не кричать "я же говорил!" если он не сойдется с реальностью

Собираемые одной и той же командой на одном и том же заводе

наверное не собираемые, а оцениваемые одной командой

Будет странно, если оценивать будет одна команда, а собирать другая :))

зато оценки будут сравнимыми :)

1. Складывать сторипоинты, желая получить человекочасы - все равно что складывать вес шкафов при переезде и рассчиывать сколько раз надо будет кататься газели с грузоподъемностью в три тонны.
2. Не складывайте. Собирайте из задач кучку и прогнозируйте по кучке. В этом плане помогают "майки" вместо поинтов.

эээээ... если это троллинг, то очень толстый :))
Один считают, вторые делают. Те кто считают, могут никогда не делать, следовательно, не знать нюансов, следовательно, неверно прикинуть трудоемкость и оценить.

Да не в этом дело, у @timporin SP аддитивность работает, судя по всему, в рамках его опыта.

Но донести мысль, что там кроме сложения оценки - забывают о том, что складываются и риски (очень вариативные) которые определяются совсем не погрешностью (погрешность это следствие), которые, при этом, пытаются обрубить коротким спринтом до @timporin  мне видимо не удалось.

Да не в этом дело, у @timporin SP аддитивность работает, судя по всему, в рамках его опыта.

Но донести мысль, что там кроме сложения оценки - забывают о том, что складываются и риски (очень вариативные) которые определяются совсем не погрешностью (погрешность это следствие), которые, при этом, пытаются обрубить коротким спринтом до @timporin  мне видимо не удалось.

Работает и хорошо. В мире, где среднее соответствуeт медиане, объемный вес соответствует массе, а сторипоинты человекочасам, можно ничего сверх этого не изобретать. Но вопрос был "почему нельзя?".