注意：在问这个问题之前，我做了一个详尽的搜索，并在其他各种问题中找到了一些答案，例如：
但是，我觉得这个问题还没有被直接解决（如果有，请告诉我）。
您是否根据在一项任务上花费的小时/天数来跟踪 Scrum 中的时间，或者仅仅是该任务是否完成？你能调整那些任务和估计吗？
背景：我们新的开发副总裁来自 Scrum 环境，所以我们都在学习这个过程，但他带来的其中一件事情是非常仔细地引用每个任务应该需要的实际时间估计值的概念完成，目的是随着时间的推移使我们的估算更加准确：因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。
但我的理解是，敏捷实践，特别是 Scrum，是基于任务是存储单个可交付目标的桶的概念，您可以在每次 sprint 之后随着客户需求的变化添加/删除/调整它们。
我意识到这可能会引起争论，但我假设将 Scrum 视为一个过程，其中只有一个概念是该系统的“正确”哲学。
您是否根据在一项任务上花费的小时/天数来跟踪 Scrum 中的时间，或者仅仅是该任务是否完成？
我跟踪估计的剩余工作量。这是一个必须有的信息。没有这个，你就无法绘制燃尽图。没有燃尽图，你不知道你在“哪里”，你不知道你的 Sprint 是否还在正轨上。这将使这个决策工具变得毫无用处。是的，燃尽图不是跟踪工具，而是决策工具。
你能调整那些任务和估计吗？
当然！
实际上，团队拥有估算，没有其他人拥有，ScrumMaster 的工作就是保证这个原则得到应用。这应该已经回答了这个问题。但还有其他原因。
正如我所说，Sprint Backlog 和 Burndown 图表是决策工具，因此应该代表您的实际情况。如果你隐藏现实，如果你不透明，这些工具将无法帮助你做出任何有价值的决定，它们将毫无用处。想一想，如果数字没用，那么好看的数字又有什么意义呢？如果它不能反映现实，那么“漂亮的燃尽”又有什么意义呢？
因此，在 Sprint 期间，团队成员显然应该尽快更新对剩余工作的估计（向上或向下）。如果任务估计最初是 6 小时，但团队发现需要完成更多工作并且任务实际上需要 8 小时，则团队应相应地更新 Sprint Backlog。如果有人在最初估计需要 4 小时但仍需要 2 小时工作的任务上花费了 4 小时，则应在 Sprint Backlog 中报告这 2 小时。如果团队发现必须完成但未确定的任务，则团队必须将此任务及其估计添加到 Sprint Backlog。只要您使用随着时间的推移收集的知识更新积压工作，一开始就不准确也不是问题。您越早进行这些更新，您就能越早适应并做出决定。
也就是说，保留“初始估计”并将其与“完成的实际时间”进行比较可能很有用。但不是为了跟踪目的，只是为了帮助团队做出更好的估计。实际上，如果你正在过渡到 Scrum，我建议不要这样做。当您学习 Scrum 价值观和原则时，通常还有许多其他障碍需要解决，还有很多其他事情需要首先改进。如果您这样做，请注意瀑布守护进程。准备好与他们战斗，他们可能会很快回来。
我在这里看到的答案没有错，但我认为他们并没有真正解决你的问题。
我想你是在问，“我应该跟踪在某项任务上实际花费的总小时数吗？” 答案是，“如果你需要，你可以，但它不是 Scrum 的一部分。”
Scrum 是一个非常轻量级的过程。它只定义/需要使 Scrum 工作所需的内容。您可以（并且在许多情况下可能应该）在 Scrum 之上覆盖其他流程，以满足您的组织需求。例如，如果跟踪实际花费在某项任务上的总小时数使您能够更好地估计未来的类似任务（正如您的副总裁所希望的那样），那么这可能是跟踪总小时数的一个很好的理由，只要它没有过多地干扰生产性工作。或者，也许您需要知道总小时数以进行计费。因此，仅仅因为 Scrum 不需要某些东西并不意味着你不应该这样做。
然而，就 Scrum 本身而言，没有必要跟踪实际花费在一项任务上的总小时数。任何 Scrum 工件都不需要它，它只跟踪估计的剩余时间量。
我不知道我们的实现是否“正确”，但我们要做的是：
然后，在每天工作后的冲刺期间，我们调整我们一直在处理的任务的时间，以便它们显示我们认为在完成任务之前还剩下多少小时。这意味着如果我有一个 6 小时的任务，工作一整天（我们认为一整天是 6 小时），然后觉得我还剩下 2 小时才能完成，然后我记下“剩余时间”从 6 到 2。如果任务是有时间限制的，我们当然需要检查实际使用的小时数。
我必须在这里添加一些东西，因为
但他带来的其中一件事是非常仔细地引用每项任务需要完成的实际小时数的估计，目的是随着时间的推移使我们的估计更加准确：因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。
很简单，不是scrum，所以我不知道你的副总裁从哪里得到他的信息。在计划下一个 sprint 之前，不会创建任务（称为 Sprint Backlog 项目）。它们是及时创建的，当然不是在项目开始之前创建的。在项目开始之前（Sprint 0），产品负责人创建产品待办列表并用故事填充它。他可以在项目期间的任何时间添加它。管理是他的。该团队在故事点或其他一些相关指标（理想的日子？）方面粗略地估计了这些故事。
以小时为单位的任务估算只是团队用来确定在 sprint 中要提交多少故事然后绘制进度以预测成功（燃尽）的工具。一旦团队凝聚并具有历史速度；它可能决定在几个小时内根本不进行任何跟踪，而只跟踪他们在故事点或故事数中的燃尽。如果团队不需要它来实现对 sprint 目标的承诺，那么以小时为单位进行估算本身就是一种浪费。
我会问副总裁这些“非常谨慎”的估计将完成什么。
只要确保你仔细并彻底估计任务。基本上你不会真正测量时间，因为它更容易出错。最好的方法是使用任务的时间估计作为故事点。这样您将获得：
但要保持时间估计，以实际查看哪些任务必须拆分或加入。
我们跟踪完成任务所花费的时间以及完成任务的剩余时间。剩余时间可以用来确定 Sprint 期间取得的进展，并预测我们是否能够实现 Sprint 目标。我们更新任务的剩余时间，每天调整它（有时会增加它）。
花费的时间 - 据说 - 用于微观管理。它还使团队有机会获得有关估算准确性的一些反馈 - 并更好地估算 - 并展示中断如何阻止团队处理 Sprint 积压工作并因此减慢它的速度。
在 Scrum 流程中，单独的可交付目标称为待办事项，可以看作是任务桶。积压项目由产品负责人确定优先级，由团队估计，首先作为一个整体，然后逐个任务。可以修改积压项目的内容、范围、优先级和估计。
我们以时间单位估计积压项目和任务（积压项目的天或周，任务的小时数），我们应用一个焦点因素（专门用于 Sprint 任务的时间比率）来考虑时间而不是花费在完成 Sprint 目标的任务上。
关于时间跟踪，您正在寻找的是燃尽图。
Fredrik 解释了烧毁是什么，但没有使用该术语。本质上，您会定期重新估计特定活动的剩余时间。
因此，对于您是否跟踪所花费的时间的问题，不一定。Scrum 喜欢利用剩余的时间来工作。（你可以用故事点代替小时，原理是一样的，正如罗伯特解释的那样。）
对于您是否可以调整任务和估计的第二个问题，绝对可以。敏捷遵循“对变化做出反应”的理念；您优先考虑对客户最重要的事情。
然而，一些团队不愿意在某个特定sprint开始后就不再添加/删除/重新确定任务的优先级，因为这几乎是一种临时的工作方式，甚至 scrum 也需要一些结构和纪律。
声明“因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。” 几乎可以肯定是不敏捷的精神。
我们使用 番茄技术来跟踪剩余时间。它的优点之一是花费的时间量以有纪律的方式记录。
在估计故事点中的故事之后，我们根据番茄时间来估计任务，并使用这个估计（可能会临时重新估计）来判断剩余的时间量。在冲刺结束时，很容易看到我们最初估计的最不准确的任务，并改进我们未来的估计方式，因为我们在每个便利贴上标记了估计和完成的番茄钟数量。
就冲刺而言，估计的剩余时间只是衡量进度的一个指标，因此我们可以看到我们在哪里烧毁了。它们是我们是否走上正轨的线索。重要的分数是完成的故事点。
根据定义，当为完全实施该项目而需要完成的所有任务还剩 0 小时时，该项目就完成了。您需要在 sprint 中跟踪剩余任务的剩余小时数。不是花在一项任务上的时间。为什么？因为我们对某件事情需要多长时间的了解并不完善，而且当我们应该在产品上工作时，试图提出一个超准确的估计，我们收获甚少。
您始终可以在 sprint backlog 项目下添加任务，因为您确定必须完成更多工作才能完全实施该项目，并且您应该每天更新剩余时间以完成（或在完成任务后将它们设置为 0 ）。
你应该告诉你的副总裁，根据你最准确的信息（今天）知道你什么时候发货，这比在过去设定一个数字/做出一个估计并且从不更新它要好得多。这并不意味着重新估计用户故事（在发布结束之前不要这样做），它意味着用新任务更新 sprint backlog，以及活动任务何时在剩余时间内完成的最佳估计。
顺便说一句，进行准确估计的方法是使用故事点来计划您的发布，根据您估计的团队速度创建迭代计划，然后根据每个 sprint 结束时的输出不断更新迭代计划。经过几次冲刺后，您将非常准确地了解团队的实际速度，从而可以轻松预测何时发布具有所需范围的版本......或者在原始发布日期之前应该完成什么范围。使用当前项目中的实际项目数据来预测项目完成是一种软件工程最佳实践，因为它是进行预测的最准确方法。