用Jira做故事点 ( Story Point)预估

预估故事的方法有很多，但是，每种方法的目标都是要更有效地预测团队在每次 Sprint 中可以完成的工作量。在敏捷 Scrum 中，这意味着要了解团队的速率。

速率用于度量一个团队在各个 Sprint 期间通常可以完成的“预估单元”的数量。它实际上是基于工作量预估的工作效率，采用除“时间”以外的其他度量方式时效果最佳。

什么是故事点？

故事点是预估 Scrum 团队中事务大小的常用度量方式。在典型的规划会议中，较小的缺陷修复可能会预估为 1 或 2，较大的功能最高可预估为 12。请注意，故事点的数值范围因 Scrum 团队而异。一些使用 1-12，其他则使用 1-5。关键是要使用相同的数值范围，以便按照一致的方式计算速率。

如果对事务预估的故事点超过了这个范围，它们可能需要拆分为较小的故事或子任务。

在这里，我们会重点介绍故事点，因为它是一种更常用的 Scrum 预估方法，我们在 Atlassian 使用的就是这种方法。贵公司可能会使用小时数或理想天数。如果您确实在使用时间进行预估，则可能需要查看配置预估和跟踪。

“哪怕是经验丰富的开发人员，也无法按小时数/天数进行精确预估。我们只要能比较有把握地预测出团队实际能完成的工作量，就可以了。一直用故事点就挺好。”

~ Atlassian 开发人员

问：为什么使用故事点，而不是小时数？

答：从长远来看，与尝试预估每个故事所花费的时间相比，大致预测团队在每个 Sprint 中能够完成的工作量显得有用得多。

借助故事点，团队能够在将故事与其他故事对比之后进行预估，而不是迫使他们确定完成每个故事需要花费的时间。然后，根据团队在每个 Sprint 中可以完成的故事点计算速率。经过几次 Sprint 后，团队速率会稳定下来，而预估精确度会提高（或者更确切地说，是获得了相同程度的不精确性）。

使用小时数进行预估的问题在于，团队可能会使用 Sprint 的“工作小时数”（以及一些缓冲时间）进行预估，这样基本上永远没法准确反映出故事的复杂性或大小。如果故事是彼此孤立地被预估（而不是通过比较），则很难获得准确的速率。

预估、时间和速率确实都是我们要理解的重要内容。请在预估事务主题中阅读更多内容。

按故事点预估，按时间跟踪

即使您按故事点进行预估，如果需要，您仍然可以按时间进行跟踪。通过了解团队的速率（与使用的度量方式无关），您能够大致猜测预估的待办事项需要花费多长时间才能完成。

但是，JIRA Software 确实也有一些专用字段（Remaining Estimate 和 Time Spent），用于在使用故事点的同时跟踪时间。

请注意：要对面板进行任何配置更改，您需要成为面板管理员。如果您创建了面板，那么您就已经是管理员了。

转到 Board > Configure > Estimation。

有关如何在项目中运用时间跟踪的更多信息，请在配置预估和跟踪主题中查找。

有趣的事实：不精确才是好的

速率的意义在于，当您面对由一系列尚未被透彻理解的故事所构成的待办事项列表时，也能够估计出需要多少次 Sprint 才能完成这些故事。这就需要待办事项中的所有预估都有相似的不确定程度。为了获得精确的速率，需要这种不精确性的程度保持一致，这就是为什么在 Sprint 开始后决不应重新预估事务的原因。

教程练习

在您的虚拟项目中，转到 Board > Configure > Estimate 页面，并将 Estimation statistic 更改为以下一种：

在创建和预估事务时，请注意它们的区别。