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