什么是敏捷中用户故事点？
故事点是用于估计敏捷开发中用户故事的相对大小和复杂性的度量单位。如果一个用户案例是1分而另一个是2分，那么2分用户案例的开发工作将是第一个用户案例的两倍。
待开发产品估计示例
￭ 用户故事＃1 - 4分
￭ 用户故事＃2 - 1分
￭ 用户故事＃3 - 2分
￭ 用户故事＃4 - 2分
￭ 用户故事＃5 - 8分
那么，为什么不用小时来估算呢？答案在于人类思维如何处理数字。
有两个例子供我们思考。首先，我们不会预测说这工作需要26或27小时。相反，我们会说任务可能需要24小时，因为我们在脑海中将此转换为3个工作日。或者我们甚至可能估计20个小时，考虑半个工作日的同时让我们变得压力山大。其次，如果我要求你告诉我一项特定任务到底需要26小时还是27小时，你可能也很无奈，毕竟1小时的差异是微不足道的，而你又不是神仙！
这两个例子反映了两个挑战：
1）任何超过8小时的努力都会导致我们开始进行心算，以便将所涉及的时间内化。
2）当数量增长时，我们难以确定我们的估计。你如何才能有力地向管理层证明一个任务、特性或用户故事需要56个小时而不是48个小时？
故事点通过将估计值围绕1个故事点的单位进行规范化来解决这些问题。因此，最小的用户故事可能需要1个故事点才能完成，而较难的用户故事可能需要更多（2、4、8等）。
这立刻解决了我们的第一个问题，因为我不再需要在估算过程中转换估算值。我正在比较总体的复杂性和工作量。人类的思想存在于相对比较的领域。因此，我们的大脑更容易判断一个用户的故事是另一个的两倍，而不是说一个需要16小时，另一个需要32小时。事实上，这样做容易得多，以至于一些公司发现，通过按故事点估算项目，他们花在项目估算上的时间减少了80%。
故事点也解决了我们在估算中关于”确认”的第二个问题。由于我们处理的是故事点，随着估算变得越来越大，我们不再为了处理相同的粒度级别的时间而忧心忡忡。我们不会以半个故事点来衡量用户故事的大小。此外，管理层也不太可能认为特定用户故事应该是2分而不是4分。然而，如果他们以小时为单位审查评估结果，他们通常会认为，对于一项特定的工作来说，80小时“似乎很长”。