但是在敏捷项目中，如何进行故事点的估算呢？

在软件开发过程中，我们可能经常听到老板和客户问我们需要多少时间来完成项目？或者到某一个时间点，产品能做到什么程度？在瀑布模式下，项目经理们基本会给出明确的项目上线时间。

但是在敏捷项目中，特别是Scrum开发框架下，项目团队变成了一个自组织团队，没有了“经理”，那我们如何开展这项工作？如何进行故事点的估算呢？

在Scrum的开发框架下，团队共担责任，集体承诺每个Sprint的工作，因此对于工作量的估算通过集体估算的方式进行。集体估算通常采用估算扑克作为工具。

估算扑克是基于共识的，游戏化的估算方法。估算扑克是宽带德尔菲法的一种变体，由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5，1，2，3，5，8，20，40，?，∞。它最常用于敏捷软件开发，特别是Scrum和极限编程。那么如何采用估算扑克进行估算呢？

分牌

在估算会议上，team中的每位人员都会得到一副纸质扑克，当然，随着移动互联网的普及，目前大多数敏捷团队使用了更为便捷的电子扑克。无论电子扑克，还是纸质扑克，牌上都需要包括这些数字1/2,1，2，3，5，8，13，20，40, ∞。

讲解用户故事

产品负责人按照排定的优先级顺序从Product Backlog中选择一个用户故事，为大家详细讲解该用户故事；team针对该用户故事进行讨论并提出问题，产品负责人逐一解答大家的问题。

当团队成员确认已经对该用户故事完全了解、无任何重大问题后，大家开始对该用户故事进行估算。

估算时，首先，选择一个比较小的用户故事，确定其故事点，并将该故事作为基准故事。然后再将其他用户故事和基准故事进行比较，得出其他用户故事的相对点数，评估完成后，进行下一个用户故事点数的评估。

估算点数差距比较大的处理办法

如果估算值差距明显，代表大家对该用户故事的大小没有获得共识，高估计和低估计的人需要给出他们评估的理由。如在某一个用户故事的评估中，有的人评估的故事点数为3，有的人评估的故事点数为13，有的人评估的故事点数为8，则评估故事点数为3和13的人需要说明评估理由，大家对该故事所包含的任务达成共识后，在对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。

如果对于同一个用户故事的评估中，可能评估的故事点数不完全一致，但点数之间差距不大，比如在3和5个故事点之间，该用户故事评估故事点数可以采用平均值法进行计算，将平均值结果与评估的故事点数比较，并把与评估故事点差值较小的故事点数作为用户故事的最终点数。

如在A故事点的评估中，共有7人参与评估，其中4人评估的故事点数为3,3人评估的故事点数为5，则取平均值后的故事点数为3.85，与评估的故事点3和5比较，平均值与故事点3差值更小，所以，该用户故事的最终点数为3，该用户故事点数评估完成。

相关的问题

在哪一个会议上进行用户故事点评估？

故事点评估一般在冲刺计划会时进行，并需要选定主持人，主持人一般由Scrum Master担任。

为什么需要产品负责人讲解用户故事？

讲解用户故事的步骤是team和产品负责人之间的交互的环节，能够帮助team和产品负责人共同加深对用户故事的理解。同时产品负责人也会根据大家的反馈，进一步完善用户故事。

根据我的经验，在讲解用户故事的过程中，千万不要指定该用户故事的负责人或明显的倾向于某些人来做这个用户故事，因为一旦指定了负责人员，可能会大大降低不负责该用户故事的team其他成员的积极性，甚至会扰乱估算的秩序与结果。

估算完成后，可以任意亮牌吗？

估算时每个人选出代表自己估算值牌面上的数字，每个人都将牌面朝下，不可立即亮牌，待team所有人员示意完成评估后，参与估算的所有人员同时亮牌。在估算过程中，团队成员之间不可以互相商讨。

这样做是为了避免影响其他参与者，如果说出一个数字，它可能听起来像一个建议，并影响其他参与者的评估。这一过程也是逐步提升team独立思考的能力的一种手段。

估算与人/天，人/时有关系吗？

估算的是一个相对值，而不是绝对值。和人／天，人／时没有关系。假设我们以开车从北京到保定的工作量为参考基准，是1个故事点，那么从北京到太原的距离大概是从北京到保定的3倍，那么我们可以估算从北京到太原的工作量为3个故事点。

估算时，需要找一个参照物进行估算吗？

每次估算时，最好使用相同的标准用户故事，这样对于整个项目的统计有很大帮助。使用相对值进行估算，可以有效的监控团队的生产能力。

对于初次实施敏捷的团队，对故事点的评估可能还是不太容易理解，根据我的实践经验，初次实施评估故事点时，可以尝试1人/天的工作量作为一个故事点（与文中描述的“故事点和人／天，人／时没有关系”这句话并不矛盾）。

产品负责人和Scrum Master参与估算吗？

关于参与估算的人员范围，team中的所有人员都要参与估算，可能的角色包括开发人员、测试人员，但不包括产品负责人和Scrum Master。这也是为什么建议team人数5-9人的原因之一，人数太少，会使估算结果偏差很大，人数太多，会拉长估算时间，降低估算效率。

评估时最大点数不超过多少合适？

取决于团队。我们团队确定的用户故事最大点数为13，超过13，会将故事卡片进行进一步的拆分。

实际开发中发现了估算失误要不要修改点数？

不必。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费了过多的时间盒精力，这是本末倒置。

有的故事卡片会比预计的先完成，有的会耗时更长一些，这些经验的积累都会为团队的下一次估算奠定更好的基础。所以，单纯地修改点数是没有意义的。毕竟快速迭代就是方便我们试错、改善。但如果做着做着发现故事卡中有深坑，建议再开一张卡片来填坑，这是比较常见的做法。

作者： 张洪强  ，微信公众号：PMO杂谈

本文由 @PMO杂谈 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Pexels，基于CC0协议