我一直在学习 Scrum，并尝试使用一个名为 Acunote 的工具来使用它。我的问题是关于每个任务的两个领域。它们是“估计”和“剩余”。我应该为那些使用什么单位？我使用故事点数吗？剩下的呢？例如，我有一个需要 10 个单位的任务，比如说。我在一天结束时用我认为需要完成的“单元”填充剩余的部分？
谢谢！
【问题讨论】：
标签： agile scrum estimation time-estimation
我有几个建议给你：
团队“认为”他们已经走上正轨是非常容易和普遍的，因为任务正在完成并被烧毁。然后他们到了 sprint 的最后，发现 5 个故事都完成了 90%，什么都没有完成。如果您烧毁故事，您实际上是在跟踪可交付的业务价值，而不仅仅是任意数量的开发人员垃圾。
【讨论】：
与往常一样，我的第一个建议是在采用/学习 Scrum 时不要使用工具（我开始厌倦了一遍又一遍地重复同样的事情 :)。相反，从可能可行的最简单的事情开始（产品待办事项的电子表格、Sprint 待办事项的白板和便利贴）。这背后的基本原理是你想学习和掌握 Scrum，而不是工具。所以不要让工具告诉你如何进行 Scrum 并推动流程。
那么，关于这个问题，有两种思想流派：1. Scrum 理论上说什么，2. 一些人在实践中做了什么。
理论上，Scrum 有两个级别的估计：一个用于在当前 Sprint 内完成的工作（任务），另一个用于更远的产品待办事项 (PBI)。在产品待办列表级别，项目（正在构建的“什么”）应该在精确度较低的故事/T 恤/无单元点中进行估计。这种方法避免了“分析瘫痪”的陷阱，并准确地反映了围绕相关工作的一般不确定性。在 Sprint Backlog 级别，项目被分解为以小时为单位估计的任务（PBI 将如何实现）。一个单独的估计方案是合适的，因为任务描述了细粒度的工作（通常大约几个小时，从不超过 16 小时）。事实上，Scrum 建议使用“理想的工程时间”进行任务级估计。
在实践中，有些人不以小时为单位进行估算，因为烧掉时间并不能显示“真实”的进展，这不是错误的，他们更喜欢烧掉故事点（这实际上意味着一个项目已经完成或不，它更二进制）。
虽然我理解后一种方法的“精神”，但我不会应用它并坚持该理论。实际上，由于前面提到的原因，以小时为单位估算对我来说确实有意义，而且我实际上发现它可以更好地“控制” Sprint 期间的 Scrum 经验过程（在每天结束时，您应该更新估算的剩余工作量不管实际花费的时间如何，这在几个小时内会更容易）。
此外，我不喜欢只有小故事的缺点（这也可以被视为浪费），但喜欢当团队清楚地确定在 Sprint 中必须完成的事情时（这有利于透明度并有助于产品负责人也了解真正的工作量，尤其是“以质量为导向”的任务）。
最后，我认为你也可以在几个小时内避免 DancesWithBamboo 提到的陷阱。请保持警惕并：
因此，在我看来，是可以使用时间并避免在 Sprint 综合症结束时出现“无所事事”的情况。只需使用您的大脑（Scrum 和/或任何工具都无法取代它，幸运的是我们）。
话虽如此，如果您不扔掉您的工具，那么要回答的问题是：您希望在燃尽图上显示什么（点数或小时数取决于您是否将工作分解为任务，我给了你我的观点）以及 Acunote 使用什么字段来绘制燃尽图（即我应该在哪里更新对剩余工作的估计）。如果您选择积分并且不使用任务，那么除非完全完成 IMO（是否完成 PBI），否则更新剩余工作是没有意义的。
【讨论】：
恕我直言，您不应该将剩余用于 SCRUM 积分，因为积分应该是非常主观的，您可能无法说出您已经走了多远。 我建议您将任务分解为更小的任务（这些将是您实现这些功能所需的步骤），然后将它们估计为几个小时。这样您就可以轻松跟踪功能的进度
【讨论】：
初始估计和剩余时间都使用小时数。任务通常以小时为单位进行估算。
您可以使用 Scrum 点 - 或任何其他单位 - 来估计积压项目。
【讨论】：
我不会为留下来而烦恼。故事或任务是布尔值（完成或未完成）。 在我们的团队中，我们开始只接受预计不到一天的任务。这样一来，任何团队成员都不应该在连续两次的每日 Scrums 中处理相同的任务。第三天肯定敲响了警钟！ 在任务中分解也很容易和快速，因为它不需要太多的估计。是否少于一天：好的，否则分解。
【讨论】：