In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
参与估算过程的 PO 存在固有的利益冲突。如果他/她真的认为团队的估计不正常，那么也许他们对所要求的内容没有相同的理解，并且应该花几分钟来获得更多的清晰度。
记住用户故事“卡片”的 3C：卡片、对话、确认。该卡片是 PO 和团队之间对话的承诺。 PO 绝对需要成为该对话的一部分（不能没有他们！），并且 PO 和团队需要理解并就所需的确认（验收测试）达成一致。
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.
发布评论
评论（3）
在“经典”scrum 中，团队在没有 PO 的情况下决定故事的估计和承诺。待办事项中的故事由团队和 PO 讨论，然后由团队达成一致。
编辑：正如 nuqqsa 和 xsAce 指出的那样，PO 的存在在估算过程中会很有帮助，因为他可以帮助澄清确切的要求，从而使估算更加精确，但他不参与实际估算。
In "classic" scrum, the team decides on the estimates and commitments of a story without the PO. The story in the backlog is discussed by the team and the PO and then agreed upon by the team.
EDIT : as nuqqsa and xsAce pointed out, the presence of the PO can be helpful during the estimation session, as he can help clarify the exact requirements and thus make the estimation more precise, but he does not take part in the actual estimating.
团队（你问题中的开发/QA，但任何致力于团队迭代交付的人（设计师、文档编写者都是我见过的）就每个故事的大小以及可以适应的总体大小达成共识 Scrum 团队通常使用两阶段
计划会议；与 PO 讨论优先级故事，并使用非时间单位（故事点、 T 恤尺寸等），然后当就迭代的内容达成一致时，将故事分解为任务，并在第二阶段对其进行估计（如果有的话，可以重新协商迭代承诺。是第一阶段和第二阶段估计之间的不一致。）
希望团队能够就理解和努力达成共识，而不是“投票”（获得最多票数的估计获胜），以便每个人都可以如果团队无法就正在使用的两个彼此相邻的估计达成完全共识，则较大的获胜。
参与估算过程的 PO 存在固有的利益冲突。如果他/她真的认为团队的估计不正常，那么也许他们对所要求的内容没有相同的理解，并且应该花几分钟来获得更多的清晰度。
记住用户故事“卡片”的 3C：卡片、对话、确认。该卡片是 PO 和团队之间对话的承诺。 PO 绝对需要成为该对话的一部分（不能没有他们！），并且 PO 和团队需要理解并就所需的确认（验收测试）达成一致。
The Team (Dev/QA in your question, but anyone who's committing to the Team's iteration delivery (designers, documentation writers are some I've seen) comes to a consensus on the size of each story, and the overall size that can fit into the iteration.
Scrum Teams generally use a 2-phase planning meeting; discussing prioritized stories with the PO, estimating them (which may reveal inconsistent understanding by Team members and/or the PO) using a non-timebased unit (story points, t-shirt sizes, etc.), and then when an agreement has been reached about what will fit into the iteration, breaking the stories down into tasks, and estimating them in the 2nd phase. (It's permissible to renegotiate the iteration commitment if there is dissonance between the the 1st and 2nd phase estimates.)
Hopefully, instead of 'voting' (estimate with the most votes wins), the Team is coming to a common consensus of understanding and effort, so that everyone can commit equally. If it comes down to two next-to-each-other-estimates-on-the-scale-being-used that the Team can't come to a complete consensus on, the larger one wins.
There is an inherent conflict-of-interest with the PO participating in the estimation process. If s/he really thinks the Team's estimate is out-of-whack, then perhaps they do not share the same understanding of what's being asked for, and a few minutes should be spent gaining additional clarity.
Remember the 3Cs of the User Story 'card' -- Card, Conversation, Confirmation. The Card is a promise of a Conversation between the PO and the Team. The PO absolutely needs to be part of that Conversation (can't have it w/o them!), and the PO and Team need to understand and agree upon the Confirmation (acceptance tests) needed.
开发/质量检查决定故事的大小和相关的估计。产品负责人与团队共享优先的产品待办事项列表，团队决定他们可以在当前冲刺中完成哪些项目。
The Dev/QA decides on the size of story and the associated estimates. Product owner shares the prioritized product backlog with the team and the team decides which items they can complete within the current sprint.