产品负责人如何参与规划扑克游戏？

Scrum Development 邮件列表中最近有一个讨论， Tri Nguye 提出问题：产品负责人是否应该参与规划扑克游戏？有大概的结论么？正如 Ron Jeffries 明确指出的：

他们应该在场么？是的，说明他们的意思。 他们应该估算么？不，除非他们准备参与编码工作。

也就是说，在规划扑克游戏中，产品负责人应该负责澄清每个用户故事的完成条件，比如：应该包括哪些功能，不要哪些功能，要达到哪些标准等等等等。但是产品负责人不应该帮助团队估算达成这些条件需要多少工作量。以规划扑克形式表示的量化工作量估算，必须由开发团队独立完成。

不让产品负责人提供估算的原因很简单。开发团队成员需要做出承诺，承诺接下来的 sprint 中要完成哪些功能。如果产品负责人可以为这个承诺施加过多影响，团队就无法真正将该承诺视如己出，因此失去很多 Scrum 中自组织所带来的力量。

然而有一种特殊情况，产品负责人可能需要提供自己的工作量估算。 Dan Rawsthorne 指出：

记住：产品负责人是一个角色，是一个人。人可以扮演其他角色，而且在这些角色中，人可能要进行工作量估算。

如果产品负责人也是一个开发人员，实际上，他可能就要在规划扑克过程中提供估算了。考虑到产品负责人角色所占用的时间，其实很少有产品负责人有时间从事开发工作。

产品负责人在估算过程中是不是必须完全沉默？也不一定。规划扑克是一种有用的工具，可以检查在产品负责人和开发团队之间的沟通误差，一旦发现沟通误差，就必须马上纠正。Henrik Kniberg 在他的《硝烟中的 Scrume 和 XP》一书中给出如下例子：

团队和产品负责人对于 sprint 计划非常满意，准备结束会议。这时 Scrum Master 说到：“稍等，这个名为‘添加用户’的故事还没有估算。咱们来看看吧！”经过几轮规划扑克活动之后，团队同意分配 20 个故事点数。此时产品负责人站了起来，怒道：“什么？！”经过几分钟热烈的讨论，发现团队错误理解了“增加用户”的范围，他们以为这需要‘一个很好的 web 图形用户界面来添加、移除、删除、搜索用户’；然而产品负责人只想要”通过 SQL 直接操作数据库，手动添加用户“。他们重新估算了以下，最后同意 5 个故事点数。

在这个例子中，规划扑克起到了交叉检查的作用，防止对于用户故事范围的错误理解。

查看英文原文： How Should a Product Owner Participate in a Planning Poker Session?