什么是故事积分的最佳解释是什么？

我们在这里开始使用Story Points进行敏捷开发，但是我很难解释，也找不到任何明确的答案。我能做的最好的事情是指向其他站点（例如http://blog.mountaingoatsoftware.com/tag/story-points），并对它们的含义进行一些模糊的概括。我正在寻找一些使用示例的良好解释，这些示例将对其他使用示例有所帮助。有没有很好的资源可以解释故事要点？

首先，这可能会有所帮助：Mike Cohn讲故事。但这要好得多：敏捷开发团队：与Mike Cohn合作的范围和规模

Mike对于软件估算指标的解决方案简单有效。生物学事实：

• 人脑只是无法正确估计时间。特别是如果超过几个小时。
• 软件开发人员的不确定性数量，管理人员的心理压力（当您估计时，您付诸实施...）以及团队技能的差异会极大地放大这一点。
• 但是，我们比较擅长比较东西。我们在那里很准确。

这个想法是获取一个参考用户故事，然后给它任意数量的（故事）点，然后其他故事将获得与该参考相关的点。

如果您的参考故事是100分，而另一个故事是三倍大，那么它将是300分。

要将故事点转换为计划时间，您必须知道自己的速度。

为了获得准确的速度，您必须进行几次迭代，并计算出团队在给定时间内完成的得分。

它可以工作。

我同意@Pierre 303的所有观点：上面说过（（除了100参考点）。

我唯一要补充（强调）的是，我们不擅长估算任务。我们可以估计相对于其他任务的任务，只要它们的大小大致相同即可。任务之间的差异越大，我们得到的结果就越差。

因此，我不同意使用起点100。

它并不是好像您将下一个任务估计为参考任务的42％。是一半的工作等于两倍的工作，三倍的工作等等。

我们的团队使用Planing Poker：在此，我们有2个故事点的参考任务。然后，我们使用斐波那契数列来估计任务：1,2,3,5,8,13,21，巨大，？相对于参考任务（不是斐波那契，我看到其他团队使用2的幂。1,2,4,8,16,32，巨大，？）我看到其他团队使用（small（1），Medium（ 2），large（3），XLarge（4）（它们计算速度时仍然有效）。

关键是，随着任务规模相对于参考任务的增加，我们变得越来越无法准确估算其成本。因此，尝试没有任何意义。这由估计轨迹末端的较大梯度反映出来。

因此，如果您的参考任务是2SP。由于任务的大小相似，因此估算1/2/3/5相对容易。一旦超过参考任务（5SP）的3倍，估计就变得更加困难（是8/9 / 10SP起作用了）。您所能说的是，它比5SP大且小于13SP，那么8SP符合要求。

SP值为13/21 / Huge的任何内容对于sprint积压来说都太大了。这些是您尚未准备好实际工作的估计（因此尚未分解成较小的任务（在您也需要之前，不要分解它们））。但是，它们确实可以为您估计产品积压中任务的大小（这允许将来进行一些计划）。当您到达要处理它们的地步时，您应该具有足够的知识将它们分解为sprint待办事项的较小任务，然后分别重新估计它们（注意：这是一个普遍的误解，认为零件等于原件）。

• 您估计的任何事情都需要分解为更小的任务。
• 任何估计为？意味着没有足够好的定义来估计
  您需要添加一个任务以明确定义该任务
  （即编写一些文档或演示文稿）。

故事点是任务难度的相对度量。这是因为人类在相对估计上实际上比精确测量要好。

使用故事点的方式是在项目上执行大约两项任务，并为其分配两个不同的故事点值。然后，使用这两个故事点近似值作为估计的基础来估计其他任务。也就是说，任务C的难度不比任务A的难，但比任务B的难易得多，因此任务仅比任务A多2个故事点。

当您估算出目前为止的所有需求后，您便可以估算一个Sprint中可以完成的需求量。在接下来的几个冲刺中，您估计已经完成了多少。如果满足要求，则仅将需求的故事点计为已完成。Scrum中没有“ 80％完成”。这是因为人类实际上并不擅长估计完整性。经过几次冲刺后，您应该对每个冲刺可以处理多少个故事点有所了解。

您如何估算？您可以使用计划扑克来确定您的开发人员认为相对于基本需求而言，需要多少工作。

我还建议阅读《敏捷武士》。在我看来，它很好地解释了这些以及其他敏捷概念。

这是有关故事点的更多链接。

这是另一个链接。

他们是在浪费时间。

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

有趣的是，这种观点现在来自Trenches上编写Scrum和XP的人，他的公司名称（Crisp）可以在世界上许多团队使用的许多规划扑克牌中找到。

OP的最后一句话：“是否有足够的资源来解释故事要点？” 是的，这本书是很好的资源。值得深思。

我能想到的最简单的解释是使用一个有形的物体，并提供一个具体的例子。

带上移动房屋。如果我从事移动房屋业务，我会知道建立一个单一的宽度通常需要5个（点，青蛙，小部件...度量形式是任意的），因此建立一个双重的宽度大约需要花费两倍的努力或10个（点，青蛙，小部件）。

程序员的心态将在此时开始讨论简化的方法。由于基础架构耗费了大部分时间以及其他类似示例，因此花费的时间不会是原来的两倍。这是不可避免的。对这是对（点，青蛙，小部件）的估计这一事实之以鼻，因为我们永远无法准确地及时估计，因此对（点，青蛙，小部件）的估计消除了我们可以做到的信念。

要知道要花多长时间才能建成，我们将利用一段时间内的趋势。因此，随着时间的流逝，我们的估算值越来越准确。

当团队准备出发时，不要忘记计划扑克。

正如其他人提到的那样，故事点是用户故事复杂度的相对度量。故事点的真正好处在于：

1. 分数由负责实施的单位（个人或团队）测量。
2. 保留有关在恒定持续时间内（速度）同一单位完成多少个聚合点的度量。

在测量故事点和跟踪速度几次迭代之后，您应该能够准确估计给定时间段内可以容纳多少故事点（迭代或冲刺（如果使用Scrum））。请注意，将此技术应用于小组并尝试将这些指标用于其他团队将无法正常工作。也就是说，如果A团队可以在两周的冲刺中完成120个故事点，那么期望B团队获得相同的结果是不现实的。

就像其他人提到的那样，计划扑克对使用这种方法很有帮助，因为它将帮助确定需要进一步完善的故事（如果票数之间存在差异，则意味着要求存在不确定性）。