Но они и так вместе оценивают) Возможно, вы хотели сказать, пусть не каждый свою часть оценивает, а задачу в целом?

Тестера ещё добавьте. Чтоб РО дать одну цифру закрытия фичи

Скорее по ходу договорятся про контракты, синхронизацию и прочее

Да

Что значит, прийти к единой, если разный объем работ там и там? Как я понимаю, к единой можно прийти тремя способами:  складывать оценки, брать большее, брать меньшее. Мы сейчас складываем.

Хорошо, если вам не нужна единая оценка, то просто держите ваши функциональные отделы раздельно и не пытайтесь из складывать

А цель в чем?
Как мне думается, есть бизнес задача, которую принёс РО и которому надо знать когда команда ее сделает. Если так, то внутри команды можно поступать как угодно и это «как угодно» зависит от зрелости команды. Если уровень зрелости не высок - ищите подобные и складывайте. При его повышении команда прийдет к тому, что фича будет оцениваться командой и выдавится единый конечный результат. Про второй вариант и писал Артем

Фишка общей оценки в том, что вы на этапе оценки проясните кучу нюансов, тем самым повысив точность оценки при минимальных затратах.

Как мне кажется, вы совсем верно используете сам механизм оценки в стори пойнтах. Это не составление сметы, которые пытаетесь вы сделать, это другое

Это мера объема работ, необходимая для того, чтобы понимать, сколько мы можем реализовать задач за спринт. Чтобы в следующем спринте брать то количество, которое нам по силам, верно?

@alina_baila Вы задали вопрос и получили ответ. Он вас, судя по всему, не устраивает. Как мы можем помочь вам продвинуться? Или это уже отвлеченная дискуссия, а ответ вам больше не нужен?

Нюанс в том, как именно эта мера получается . Вся соль именно в групповой оценке, что позволяет с минимумом затрат получить достаточную точность.

У Майка Кона в Agile планировании это хорошо объяснено

так Кон же мошнник

Ответы приняла во внимание, спасибо. Пытаюсь, выяснить, чего я недопонимаю. "Это не составление сметы, которые пытаетесь вы сделать, это другое" - хотелось спросить, что другое? Но потом решила написать, как я понимаю, и проверить, правильно ли считаю

Убывающая предельная полезность - не его изобретение, энивей)

А в чем мошенник, не знал?

А подскажите такой вопрос: есть итерации, PO выдает на грумминге задачи, они составляют потом беклог спринта, и команда говорит: "Мы не понимаем общего хода проекта" - при этом есть роадмап, но действительно им же даются задачи, которые не покрывают полного функционала какого объекта системы? Какие выходы?

задать этот вопрос ПО и команде

я ПО...

так иди те на ретро и обсудите этот вопрос)

В смете в чем прикол, потом, если пошло превышение сметы, то влетают отдельные исполнители, кто превысит свою часть.

При командной оценке оценивать учиться вся команда. Артельная ответственность. В итоге повышается прозрачность, что является неотъемлемым свойством лучших команд

команде задавал вопрос... они просят очень много коммуникаций, при этом вы сами понимаете если я объясню даже 50%, то из этих 50% останется в голове 44% на первый день