在Scrum Master的指导下，团队成员需要对各项Sprint Backlog耗时进行事前估算，但由于估算在个体理解、方案选择、方案实施方面存在差异，因此不同的成员对于同样的Sprint Backlog得出的估算值可能大同小异，也可能相差悬殊。如果大同小异，表明团队成员在个体理解、方案实施等方面已经达成共识。如果相差悬殊，表明团队成员在个体理解、方案选择等方面存在很大分歧。
如果存在分歧，Scrum Master会要求敏捷团队成员做以下事情：
●每个成员说出估算时间的具体理由。
●成员之间相互讨论，认可哪些理由，不认可哪些理由。
●对于认可的理由，重新预估时间。
●再次讨论，如果团队成员达成共识，那么该预估时间即为最终的预估时间。
Scrum团队采用共同估算的方法对各项Sprint Backlog耗时进行估算。在估算前不应该指定谁将开发这个用户故事，而是以Scrum团队小组为单位进行集体估算，每个人提出自己的看法，这样才能以集体智慧完成任务。在整个估算过程中，产品负责人不能离开，因为很多估算差异来自“做什么，做到什么地步”，对于这些问题产品负责人需要予以解答，而不是让团队成员按自己的理解去做。
共同估算的目的不是寻求一个数字上的统一，而是用集体智慧对“做什么，怎么做”达成共识。共同估算的过程也是Scrum团队成员对用户故事再理解的过程。共同估算是共同跟进的基础，若不能共同估算，则后面的“每日立会”几乎不可能正常进行，因为大家只会关心自己曾经一起分析、思考、提问、设计乃至争论过的任务进展，是否与自己当初想象的一样。
共同估算的最佳方法是“敏捷扑克估算法”，这看似一个小游戏，但却是Delphi估算的一个快速方法，同时体现了匿名性与高效性。
敏捷扑克估算法（Planning Pocker）
敏捷大师Mike Cohn推荐使用敏捷扑克对Sprint Backlog用户故事进行估算。每张扑克牌正面印有表示用户故事的点数，即预估时间。当Scrum Master要求公开各自的工作点数的时候，每个成员必须同时亮出印有预估时间的扑克牌。
与其他估算方法相比，使用扑克牌的方法，可以增进团队成员间的信息交流和信息共享。当估算数值差大于可接受的范围时，估算数值最大和最小的两位成员要各自解释理由，即自己的预估时间是如何得到的，详细讲述预估时间是如何一步一步通过估算求得的。
敏捷扑克估算过程中，每个成员都会对Sprint Backlog进行再思考：
●自己理解的需求是否准确？
●自己预想的实施方案与其他成员是否一致？
●哪个方案更优？
●是否还有哪些技术层面的因素未考虑？
●是否还有其他依赖条件未考虑？(www.xing528.com)
团队中所有人都有机会发言，分享自己所了解到的知识，也可以学到其他人分享的知识，既有助于提高团队凝聚力，也有助于提升开发效率和质量。
图3-10 敏捷扑克
如表3-8所示，假设敏捷团队共有5名成员（A—E），对于“智能话机反极性计费功能”这条Sprint Backlog预估的时间，5名成员分歧较大，成员C认为用8人时[2]就能完成，而成员D认为需要用24人时才能完成。Scrum Master要求每个成员说出估算的详细理由后，再次进行讨论。成员D的理由中提到“与现有的服务器计费兼容性验证”，而该流程却被其他成员所忽视，经讨论，其他成员都同意该流程的实施，但认为“与现有的服务器计费兼容性验证”方案实施所需的8人时预估时间过大，4人时应该是合理的时间。最后每个成员对该Sprint Backlog实施所需的20人时预估时间都没有异议，达成一致。
表3-8 对Sprint Backlog预估时间产生分歧的处理方法
敏捷扑克估算的常见问题（在师徒制度中）
（1）为什么估算任务要让Scrum团队成员都参与而不是分配给个人？
Scrum团队成员的参与使得团队中每个成员都不得不动脑筋思考，因为一旦出错了牌又说不出原因将会是非常尴尬的事情。另外，即便该成员日后不做这个用户故事，对其深入了解，也便于经验分享和信息交流。
（2）为什么不让师傅估算、徒弟采纳，师傅不是最厉害吗？
师傅对用户故事的功能理解，以及对用户故事的技术实现方案，徒弟一时未必能够理解。共同估算就是让大家在思考过程中对照自己原先的实现方法，发现与师傅的差异，通过这一比对过程加深对需求的理解，便于确定方案。
（3）为什么不让最后领任务的人自己估算？
最后领任务的人可能因能力所限，不清楚某代码可用、某方案不可行，或者不懂设计模式，而选择了错误的实现方法。
（4）Product Owner参与估算岂不是会干预他人？
很多问题比如在游戏中“显示武林排行榜”，具体工作量可能不在于怎么做而在于做什么、凭什么排名、排多少名、实时排名还是每周排名、怎么显示排名等。因此，Product Owner不可能写出一堆文档，然后以不便干预估算为由不参与敏捷计划会议。
Product Owner可以质疑估算，比如，“这真的要这么久吗？我记得上次……”。但要有理有据。其实实践中更容易看到的是，团队往往过于激进和乐观，Product Owner反而要让他们意识到完整的需求和要求，以便做出更现实的估算。若估算不准确，Product Owner也要担责。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
