1. Способ принятия решений это не догма, как и все в скраме. Его выбирает команда. Можете использовать a) классический подход - консенсус (демократично, но медленно), b) решать большинством (менее демократично, но быстро), c) доверить оценку тем, кто наиболее вероятно будет делать задачу. В т.ч. это можно делать за рамками скрам-митинга, хотя и не рекомендуется. Если в случае b) голоса разделились поровну, то можете либо продлить обсуждение, пока один человек не изменит мнение, либо всегда использовать правило выбора меньшей (вызов) или большей (запас) оценки.
2. Судя по описанию, проблема в том, что команда пока не вполне зрелая для agile. Среди ценностей гибкой разработки важную роль играют взаимное доверие и самоорганизация. Если люди обижаются, когда другие не соглашаются с их мнением, это означает, что они ставят свое эго выше интересов команды. Так бывает в командах, которые стали командой просто по назначению начальства. Берут сам фреймворк, процедуры, но никто не думает о главных принципах. Внедрение ценностей скрам - дело скрам-мастера. Объяснять, воспитывать, в первую очередь собственным примером. Как только появится несколько лидеров, которые проникнутся - остальные подтянутся. Дальше - будет легче. Новички будут адаптироваться наблюдая за остальными.
Чтобы люди не пытались "попасть в ту же цифру" используйте planning poker. А цель обсуждения - не "отстаивать свое мнение", а дать команде больше информации для принятия взвешенного решения.
