什么是故事点
故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。
当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。
什么是故事点的基准
故事点的估算是一个相对值,和天/人或时/人没有直接关系，所以我们需要先选一个基础故事作为故事点评估的基准。
假设孩子和成年人从家里出发到学校（1x距离），可能孩子走20分钟才能到达，大人只需要10分钟，但如果他们在这个距离上达成一致意见，即这就是1个故事点，同理在从家到医院的路程上（3x距离）大人和孩子都可以给出3个故事点的估算。
故事点评估方式，允许即使具备不同能力的人，也可以达成一致的估算。
故事点的点数
故事点的点数评估是基于团队共识、游戏化的估算方法,是宽带德尔菲法的一种变体，由一组类似斐波纳契数列的数字组成。
这些数字包括：0，0.5，1，2，3，5，8，20，40，?，∞
影响故事点评估的因素
由于故事点数代表了开发用户发故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。
- 工作的数量
- 工作的复杂度
- 工作中存在的任何风险或不确定性
如何提高故事点评估的准确性
复杂工作的评估
对于复杂的工作可以采用任务拆分的方式,把大的工作拆分成一个个相对简单独立的任务，评估每个任务的工作量。
风险或不确定因素的评估
- 工作实现的技术风险或不确定
对于棘手的技术或设计问题，可以为它创建一个穿刺方案（spike solution）。所谓穿刺方案，是指一个非常简单的程序，专门用于探寻潜在的解决方案。
如果有一个技术难题给整个系统的开发带来了威胁，有可能导致整个团队开发受阻，那么就应该安排一对程序员专门花一段时间对这个问题进行穿刺，降低风险。穿刺的时间最好控制在1~2天，最好不要超过5天。
构造穿刺方案的目的是为了增加故事点评估的可靠性，所以我们只关注要验证的特定技术/设计问题，无视其他方面的考虑。因此，穿刺方案的质量通常不会很好，你应该做好准备，完成验证之后就将其丢弃。
- 工作实现的外部依赖风险或不确定
故事点评估流程
1. 分牌
在估算会议上，team中的每位人员都会得到一副纸质扑克,这些扑克包括这些数字1/2,1，2，3，5，8，13，20，40, ∞。
2. 用户故事讲解
产品负责人按照排定的优先级顺序从Product Backlog中选择一个用户故事，为大家详细讲解该用户故事；team针对该用户故事进行讨论并提出问题，产品负责人逐一解答大家的问题。
当团队成员确认已经对该用户故事完全了解、无任何重大问题后，大家开始对该用户故事进行估算。
估算时，首先，选择一个比较小的用户故事，确定其故事点，并将该故事作为基准故事。然后再将其他用户故事和基准故事进行比较，得出其他用户故事的相对点数，评估完成后，进行下一个用户故事点数的评估。
3. 团队成员估算后亮牌
估算时每个人选出代表自己估算值牌面上的数字，每个人都将牌面朝下，不可立即亮牌，待team所有人员示意完成评估后，参与估算的所有人员同时亮牌。在估算过程中，团队成员之间不可以互相商讨。
这样做是为了避免影响其他参与者，如果说出一个数字，它可能听起来像一个建议，并影响其他参与者的评估。这一过程也是逐步提升team独立思考的能力的一种手段。
4. 估算点数差距比较大的处理办法
如果估算值差距明显，代表大家对该用户故事的大小没有获得共识，高估计和低估计的人需要给出他们评估的理由。如在某一个用户故事的评估中，有的人评估的故事点数为3，有的人评估的故事点数为13，有的人评估的故事点数为8，则评估故事点数为3和13的人需要说明评估理由，大家对该故事所包含的任务达成共识后，在对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。
如果对于同一个用户故事的评估中，可能评估的故事点数不完全一致，但点数之间差距不大，比如在3和5个故事点之间，该用户故事评估故事点数可以采用平均值法进行计算，将平均值结果与评估的故事点数比较，并把与评估故事点差值较小的故事点数作为用户故事的最终点数。
如在A故事点的评估中，共有7人参与评估，其中4人评估的故事点数为3,3人评估的故事点数为5，则取平均值后的故事点数为3.85，与评估的故事点3和5比较，平均值与故事点3差值更小，所以，该用户故事的最终点数为3，该用户故事点数评估完成。
常见问题
评估时最大点数不超过多少合适？
取决于团队。建议团队确定的用户故事最大点数为不要超过一个迭代周期，超过了就要将故事卡片进行进一步的拆分。
实际开发中发现了估算失误要不要修改点数？
不必。估算是为了辅助我们的工作安排，而不是用来管理员工的绩效表现。为了达到精准的估算而耗费了过多的时间盒精力，这是本末倒置。
有的故事卡片会比预计的先完成，有的会耗时更长一些，这些经验的积累都会为团队的下一次估算奠定更好的基础。所以，单纯地修改点数是没有意义的。毕竟快速迭代就是方便我们试错、改善。但如果做着做着发现故事卡中有深坑，建议再开一张卡片来填坑，这是比较常见的做法。