故事点 是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能的难易程度、风险和花多大的功夫。
故事点（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天的时候，那么这个迭代的目标就确定了。这是很多团队实际采用的方式，看起来好像没问题，但是久而久之，这种方式的弊端就会显现出来。
自己干自己的，不关心全局的进展。既然每个人自己的工作内容都已经确定，那每个人安排好自己的工作就可以了，何必关心别人的工作呢？
抗风险能力差。如果A君请假1天，需要C君花4天才能弥补。不仅对C君的计划影响巨大，也让整个团队的预估和实际相差甚远。
看不到团队的真实速率。每当PO询问某些用户故事能不能安排到下个迭代时，通常得到的答案是“这要看谁有没有空”。
不利于团队成员的成长。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扑克牌。
这些纸牌表示的意思是：
0表示喝口水的时间就能完成。
其他数字是根据和基准故事对比得出的结论。
?表示复杂度未知，通常需要对用户故事进行讨论或者拆分。
咖啡表示估算的太久，有点累了，需要休息一下。
原则上，一个好的敏捷团队，不应该为超过8个故事点的用户故事估算，大于等于8个故事点的用户故事应该被拆分为更小的用户故事。而随着时间的推移，T团队中会出现越来越多的基准故事，这些基准故事对应的故事点可能是1，也可能是2，也可能是3。这使得所有人对于新用户故事的估算越来越准确。
当然在实际的工作中，由于每个人实际情况的不同，即使所有人都明白1个故事点意味着什么，依然会为一个用户故事的故事点是2还是5而产生争论。有的人考虑的多，有的人考虑的少，有的知道一些近路，有的人一脸茫然。正确的步骤是这样的：
所有人先不要说出自己的故事点，而是将对应的纸盘扣在桌子上。
当所有人的纸牌都扣在桌子上时，大家一起翻开自己的卡牌。
请估算差异最大的两位成员讨论，各自估算的原因。
所有人收回纸牌，重复步骤1-4。直到所有人的估算一致为止。