4.纠结的估点
估点的意义不是为了得到精确的工作量这个数字，而是通过估点这个过程把这个故事的复杂度找出来。
1.估点的流程
PO在讲完故事后，SM让开发人员对这个故事有什么疑问没有，有疑问PO继续答疑，如果大家都没有疑问SM会要求大家出点，这时候每个人手上都有一副敏捷估点扑克牌，每个人会把自己估算的点数对应的扑克牌抽出来，放在桌上盖起来，不能提前翻看让别人看到，等大家都出牌后，SM会让大家一起亮牌。一般来说大家出的牌肯定会不同，这时候SM会要求出最大牌的人说一下自己的理由，然后让出最小牌的人说一下自己的理由，说理由的过程中肯定会引发大家的讨论。等这两人阐述自己的理由完之后，SM会要求大家再重新出牌，这次基本上大家的点数就会差不多了，如果还是最大和最小差别很大，那就最大和最小再说明自己的理由，然后继续估点，如果第三次还是相差很大，那么表示这个故事大家没有搞得太清楚，那么就先把这个故事放一边，看后面的故事。等本次迭代所有故事都估完后，再拿起这个故事进行估算，大多数这时候就能过去了，因为故事之间是有关联关系的，刚开始可能对这个故事的复杂度看不准，看完后面的故事后就有可能有把握了。万一到最后还是估不出来，那一定是故事本身有问题，可能太大了或者需求不明确，这时候就让PO收回此故事完善好后，放入下个迭代再开发。
我们用的估算扑克牌上的数字是斐波纳契数，1、2、3、5、8、13、21，还有两张喝咖啡和问号的牌，后来我们把大于3的扑克牌都不允许出了，因为太大的点没有意义，点越大表示估算肯定准确程度就越低，还有就是我们的基准点（1个点）团队成员完成它需要1天的工作量，而我们一个迭代两周，每个人开发的时间只有8天，你做一个5个点的故事，那就会出现头一周都完不成一个故事，导致然尽图根本就没法将下来，迭代失败的风险也就越高，所以我们最后决定大于3的牌都不允许出了，一般遇到大于3个点的故事，PO都会拆分成多个故事。当然这是我们团队的方法，别的团队的基准点可能没有这么大，那么大点也还是有用的。另外还有一张问号的牌就是在估出来的点太大或者估不出来的时候就出它，喝咖啡的牌表示自己需要休息一下。
2.估点不会被夸大，只会估得过于乐观
我们做了这么多个迭代，确实没有出现开发人员刻意去夸大故事点，反而有失败的迭代故事点的复杂没有考虑完整，导致估点乐观了。估点过程中，SM一定要把握好，一定要引导大家正确的估点，而不是让大家跟风，或者随便说一个点数，但又说不出理由，这种估法肯定就有问题，SM一定要纠正大家。
3.基准点的作用
基准点是一个参照物，所有故事估点都必须是它的相对值，所以选定的基准点必须是大家都做过的功能好一点。我们团队选定的基准点是一个单表操作的字典维护功能，包括增删改查等功能，如何估算了，比如单据维护的故事，包括单据头和单据明细，那么对比基准点，单据头有增删改查的功能，单据明细也有增删改查的功能，所以我们会估2个点。不能这样搞，我做过这种类似的单据维护功能，我只需要1个点，这就是错误的估点方式，又比如我估3个点，因为除了两个增删改查还要实现单据头和单据明细的关联，因为要关联展示所以多一个点。你说出的理由大家如果都认可的话，那下次出点的时候肯定就会把这个因素考虑进去。
4.估点不是站在自己的角度来估，而是站在团队的角度。
估算为什么采用点数，而不是工时，因为工时是一个绝对值，而点数是一个相对值，这个故事对于你是2个工时，而对于我则需要5个工时，因为每个人的饭量是不一样的。点数只是一个对比基准点的相对值，所以基准点的定义很重要，团队一定要达成一致。我觉得工时会不自觉的让大家站在自己的角度来估算，而点数则不会这样，所以做敏捷一定不能用工时来估算。后面领用故事的时候，并不是由SM或PO来分配故事，而是随机分配或自由领用，只有采用点数才合适。团队一个迭代能完成多少个点，是有一个比较稳定的值的，也就体现团队的速率，是有团队每个开发人员能够承担点数之和，团队中经验丰富的老手承担的点数肯定比新入职的点数要高，老员工我们是10个点的话，新员工我们只给分配给他5个点或更少，随着新人的成长对应的点数肯定也会提升。
团队中有开发人员和测试人员的话，那测试人员要怎么估点了，我们是开发人员站在开发的角度估点，测试人员站在测试的角度估点，开发和测试都是同一个基准点，本来基准点里即包含有开发也包含测试工作。如果测试估的点大于开发估的点，那一般这种故事的测试工作量比开发工作量大，最后故事的点数肯定采用大的。
还有一个疑问就是，测试执行工作必须在开发完成之后做的，所以都觉得估算的点数是不是应该开发的点数加上测试的点数才对，其实不是，第一测试的大部分工作量并不是在测试执行阶段，而是在测试用例编写，第二就是就是测试用例编写阶段是可以与开发并行的而不是串行的，所以开发和测试相加是不太合理的。
5.估点的意义不是为了得到精确的工作量这个数字，而是通过估点这个过程把这个故事的复杂度找出来。
产品开发除了进度很重要，产品的质量更重要，质量不行的产品最后还是要返工的。如果你开发之前对这个故事的复杂度了解得越清楚，那么你在开发过程中就会越顺畅，任务安排得也就越合理。另外敏捷就是注重团队整体的成功，所以一些难点应该利用团队的力量来解决，同时团队中的每个人也可以更快得获取成长。
团队一定要有这个认识，不是说点数差不多，而忽视这些点数背后的理由是不行的。
