风险和不确定性（Risk and Uncertainty）
用户故事的风险和不确定性会影响其故事点估算值。
如果用户故事的干系人在询问需求时说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。
如果要实现一项功能时需要改动一段缺乏自动化测试、结构脆弱的老代码，那么估算结果中也应该反映这个风险。
复杂度（Complexity）
在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。
现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或身份证号；另一些字段则需要做银行卡号的校验和验证。
页面上的字段之间还要相互交互。如果用户输入的是一个189开头的号码，则运营商字段默认显示中国电信。但是如果用户输入的是一个139开头的号码，则运营商字段默认显示中国移动。
尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。
这种额外的复杂度都应该反映在所提供的估算结果中。
5.3. 使用规划扑克集体估点
规划扑克在4.2节介绍了怎样使用“德尔菲法”降低从众效应的影响，在敏捷开发中，我们可以借助规划扑克来进行匿名投票。在估算会议上，团队中的每位人员都会得到一副纸质扑克，当然，随着移动互联网的普及，目前大多数敏捷团队使用了更为便捷的电子扑克。这里有2张扑克的含义需要解释下：
如果有人出了“☕️”这个扑克，说明需要休息一会了；
如果有人出了“？”这个扑克，说明他不了解需求，无法估算工作量，PO需要尝试重新澄清需求。
同4.2节介绍的案例一样，我们在规划故事点数时，第一轮大家的估点可能也会有很大的差距。如果估算值差距明显，代表大家对该用户故事的工作量、风险和不确定性、复杂度没有达成共识，估点高和估点低的人需要给他们一个机会阐述如此估点的理由。大家对该故事所包含的细节达成共识后，再对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。如果对于同一个用户故事，估算的故事点数可能不完全一致，但点数之间差距不大，比如在3和5个故事点之间，该用户故事的故事点可以采用平均值法进行计算，计算方法是将估点的平均值与斐波那契数列相比较，并把与平均值差值较小的故事点作为用户故事的最终点数。如在A故事的估算中，共有7人参与估算，其中4人估算的故事点数为3，3人评估的故事点数为5，则取平均值后的故事点数为3.85，与斐波那契数列中的3和5比较，平均值与故事点3的差值更小，所以，该用户故事的最终点数为3，该用户故事点数估算完成。
5.4. 其他
关于故事点估算还有很多小细节，我大概列一下我的看法，就不详细展开了，各位读者如果有更好的做法，欢迎留言指教：
在哪一个会议上进行故事点估算？
如果需求梳理会出席的人数较多（达到团队人数的2/3以上），就在梳理会上进行；如果人数较少的话就在计划会前单独召开一个简短的估算会议进行估点。不建议在计划会上估点。
估算完成后，可以任意亮牌吗？
不可以，必须一起亮牌，并且在估算过程中，团队成员之间也不可以互相讨论估算的点数。
PO和SM参与估算吗？
不参与。只有开发团队参与估点。注意是“开发团队”，它包括了开发和测试人员，而不仅仅是开发人员。
超过多少点数的用户故事需要重新拆分？
每个团队的基准故事点规模不一样，所以没法给个确切数字，但是建议刚组建的敏捷团队最好不要超过5，后期可以根据团队的反馈进行调整。
实际开发中发现了估算失误要不要修改点数？
不要。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费过多的时间精力，这是本末倒置。而且就我的经验来看，一个迭代中确实会有一些故事的点数被低估，但是也会有一些被高估的故事，所以就迭代整体来看，故事点不会波动太大。
很小的需求，也必须要团队集体估算吗？
要。估点是团队对需求理解对齐的过程。如果需求真的很小，估点的过程也会很快达成一致的，不会耽误大家多少时间。
规模化敏捷中的各个团队如何统一估算基线？
首先从各个团队召集一些骨干成员（每个团队最好能有2-3名），组成一个跨职能的估算团队；然后从整个产品待办列表中随机选择10-20个故事进行基准故事点的定义和估算工作，估算的过程中如果有人对相关的技术或需求不清晰，可以放弃；最后，参与估算的人，将这10-20个估点后的故事带回自己的团队，并将基准故事和其他故事的估点同步给团队，以此对齐大家对工作量的认识。
