story point
Michael de la Maza提出这样一个问题：故事点到底是什么东西？他不断寻找，并找到了很多答案，比如“故事点表示模糊的时间单元”，或者“故事点是Scrum团队使用的一种随机度量方式，用来度量实现一个故事需要付出的工作量”，还可能是“故事点数的估算混合了对于开发特性所要付出的努力、开发复杂度、个中风险以及类似东西”【引自Mike Cohn的《敏捷估算与规划》】。
Michael接下来记录了故事点的使用方式：“说实话，速度是度量生产力的一种方式”，以及与之相对的“使用故事点数或理想人天来度量生产力是坏主意，因为这会促使团队不断膨胀一个点数的内涵……”
面对这些迷惑，Michael开始思考故事点数到底是什么？你要怎么向新接触敏捷和Scrum的人介绍这个概念呢？
Dan Rawsthorne的回复是：
团队常常希望速度成为成产力的度量指标，这样就能跟外界其他人说自己的“速度有多快”。 如果故事点数在项目生命周期中能保持常量，速度才是有意义的度量指标。想做到这一点，团队必须找到一两个标准的故事，它们的大小在整个项目生命周期中都得保持不变。 如果“基线故事不仅在一个团队内部保持大小不变，而且在各团队之间也是如此，那么速度不仅可以用来度量生产力，还能用做不同团队工作效率的有效对比，并因此而成为组织内部的添加剂。”多说一句，这篇文章的作者非常反馈这个实践：速度在敏捷项目中的错误使用。 一旦团队有了稳定的故事点数，它们就能被用在未来的发布规划中，用以得到即将成功完成的工作的大致估算。 Ron Jeffries的回复是：
故事点数是需要实现一个故事所付出时间的相对度量，借鉴于XP（故事这个概念也是如此）。它们应该被用来估算困难程度，而不是承诺一个特定的时间阶段，这样不同的团队规模或是任务上花去的时间就不会影响故事点数”。 他还说：
是的，它们用来度量规模和复杂度。使用‘规模’和‘复杂度’这两个词，是要表达‘用完成任务所需时间来表示难度’。” 最后，Ron说他（和其他专家）不再认为故事点数是必要的了。
InfoQ之前有关新闻：Sprint规划：故事点数 vs. 小时数
查看英文原文：What is Story Point? Are they Necessary?