故事点是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。
故事点（story point）和预估时间（estimated）不一样，故事点是一种相对的估计，它并不能和类似“人/天”这样的单位画等号，因为每个人完成同样复杂度的工作所需的时间是不同的。我们举个例子说明一下：
假设T团队有A、B、C三位员工，A君的能力是B君的2倍，B君的能力是C君的2倍（能力是不能这样对比的，这里只是方便说明问题），T团队约定10天为一个迭代，现在他们想计划一下未来的工作。如果按照预估时间的方式，一个用户故事B君觉得需要1天，A君觉得0.5天就可以，C君觉得需要2天，那么他们最终定多少呢？
这里可能出现两种结果：
第一种结果，A君说这个我来做，写0.5天吧！如果按照这个方式，那么整个计划会议就演变成分工会议，A君挑若干的用户故事，自己进行估时，B君和C君也是如此，当每个人的总估时都逼近10天的时候，那么这个迭代的目标就确定了。这是很多团队实际采用的方式，看起来好像没问题，但是久而久之，这种方式的弊端就会显现出来。
1. 自己干自己的，不关心全局的进展。既然每个人自己的工作内容都已经确定，那每个人安排好自己的工作就可以了，何必关心别人的工作呢？
2. 抗风险能力差。如果A君请假1天，需要C君花4天才能弥补。不仅对C君的计划影响巨大，也让整个团队的预估和实际相差甚远。
3. 看不到团队的真实速率。每当PO询问某些用户故事能不能安排到下个迭代时，通常得到的答案是“这要看谁有没有空”。
4. 不利于团队成员的成长。C君很难有机会做一些复杂的，对自己能力有提升的工作，因为出于时间成本的考虑，复杂的工作都交给A君来处理。
当然，还有第二种可能，大家决定取个中间值，可是中间值定多少才算合理呢？预估的时间多就意味着整体完成的工作量变少，预估的时间少意味着完不成的概率会增大。
不同于预估时间，故事点关注的是复杂度，让所有人对同一个用户故事有相同的复杂度认知。为了做到这一点，T团队可以找到一个基准的用户故事（下文称为基准故事），基准故事不一定是最小的，但是一定能在T团队中每个人心中引起共鸣，然后T团队将第一个基准故事定义为1个故事点。
在估算一个新的用户故事X时，所有人都需要思考，故事X比基准故事更花时间吗？如果故事X的复杂度是基准故事的2倍，那么很显然，故事X的故事点应该为2。需要注意的是，故事点的取值要遵循斐波那契数列（1、2、3、5、8、13、21、34… ），不过为了方便记忆，在实际的操作中，很多团队将21替换20，34替换成40等等。下图是我的Scrum扑克牌。
这些纸牌表示的意思是：
1. 0表示喝口水的时间就能完成。
2. 其他数字是根据和基准故事对比得出的结论。
3. ?表示复杂度未知，通常需要对用户故事进行讨论或者拆分。
4. 咖啡表示估算的太久，有点累了，需要休息一下。
原则上，一个好的敏捷团队，不应该为超过8个故事点的用户故事估算，大于等于8个故事点的用户故事应该被拆分为更小的用户故事。而随着时间的推移，T团队中会出现越来越多的基准故事，这些基准故事对应的故事点可能是1，也可能是2，也可能是3。这使得所有人对于新用户故事的估算越来越准确。
当然在实际的工作中，由于每个人实际情况的不同，即使所有人都明白1个故事点意味着什么，依然会为一个用户故事的故事点是2还是5而产生争论。有的人考虑的多，有的人考虑的少，有的知道一些近路，有的人一脸茫然。正确的步骤是这样的：
1. 所有人先不要说出自己的故事点，而是将对应的纸盘扣在桌子上。
2. 当所有人的纸牌都扣在桌子上时，大家一起翻开自己的卡牌。
3. 请估算差异最大的两位成员讨论，各自估算的原因。
4. 所有人收回纸牌，重复步骤1-4。直到所有人的估算一致为止。
使用这种方式的好处是显而易见的，它能让所有人对这个故事点有一个共识，这意味着，不管谁来完成这个用户故事，那么他是认可这个故事点的。而且它可以有效的避免不假思索的跟风行为，每个人必须对用户故事的复杂度进行思考，才能给出一个相对可靠的故事点，否则就要向所有人进行解释。
使用这种方式也有它的弊端，那就是计划会议非常耗时。在实践中，有的团队将估算的环节放在计划会议之前，而有的团队不借助扑克牌，而是直接通过全员讨论得出一个相对正确的故事点。
T团队对于用户故事的估算是需要不断的磨合的，同时还有一个需要不断磨合的是团队速度。A君B君C君已经在计划会议中为若干个用户故事完成了估算，总故事点约为40，那么T团队能够完成这个40个故事点吗？实践是检验猜测的唯一方式。
随着几个迭代的尝试，T团队发现30个故事点的工作量刚刚好，不紧也不慢，那么T团队的团队速度即为30个故事点/10天。
团队速度的作用之一是，如果T团队在一个迭代中规划了总计为30个故事点的用户故事，不管每个用户故事是A君B君C君谁来做，理论上这些用户故事T团队都能按时完成。当然T团队的速度不是一成不变的，下图是我所在的团队最近三个迭代的团队速度。
（截图来自Worktile Agile）
根据过去一段时间的团队速度来规划下一个迭代的工作规模，是非常科学的。
T团队对自己团队的能力有着清晰的认识，也对迭代的目标充满着信心。另外，T团队还可以根据自己的团队速度，在迭代中插入一定比例的非功能性需求。
除了团队速度，使用故事点也可以非常直观的体现T团队在一个迭代中的工作进展，下图是我所在的团队Sprint 10的燃尽图。
（截图来自Worktile Agile）
燃尽图的趋势可以有效的体现T团队目前是否失控，如果燃尽图总是居高不下，所有人需要在站立会议中进行讨论，共同发现、承担并解决问题，这才能称得上是一个团队，不是吗？
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
