关闭。这个问题不符合 Stack Overflow guidelines 。它目前不接受答案。
想改善这个问题吗？更新问题，以便堆栈溢出为 on-topic。
3年前关闭。
Improve this question
注意:在问这个问题之前，我进行了详尽的搜索，并在其他各种问题中找到了一些答案，例如:
但是，我觉得这个问题并没有被直接解决(如果有，请告诉我)。
您是否将 Scrum 中的时间作为一项任务花费的小时数/天数的函数来跟踪，或者只是该任务是否完成？你能调整这些任务和估计吗？
背景:我们的新开发副总裁来自 Scrum 环境，所以我们都在学习这个过程，但他带来的一件事是非常仔细地引用每个任务应该需要的实际小时数估计的概念。完成，目的是随着时间的推移使我们的估算更加准确:因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。
但我的理解是，敏捷实践，特别是 Scrum，基于任务是存储单个可交付目标的桶的概念，您可以在每个 sprint 之后随着客户需求的变化添加/删除/调整它们。
我意识到这可能是有争议的，但我认为将 Scrum 视为一个过程，只有其中一个概念是该系统的“正确”哲学。
最佳答案
我跟踪 估计剩余工作 。这是一个必须有的信息。没有这个，你就无法绘制燃尽图。没有燃尽图，你不知道自己“在哪里”，你不知道你的 Sprint 是否仍然在正轨上。这将使这个决策工具变得毫无用处。是的，燃尽图 不是 一个跟踪工具，它是一个决策工具。
当然!
实际上， 团队拥有估计 ，没有其他人，ScrumMaster 的工作是确保应用此原则。这应该已经回答了这个问题。但还有其他原因。
正如我所说，Sprint Backlog 和 Burndown 图表是决策工具，因此应该代表您的实际情况。如果你隐藏现实，如果你不透明，这些工具将无法帮助你做出任何有值(value)的决定，它们将毫无用处。想一想，如果数字没用，那么好看的数字又有什么意义呢？如果它不能反射(reflect)现实，那么“看起来很漂亮的燃尽”有什么意义？
因此，在 Sprint 期间，团队成员显然应该尽快更新对剩余工作的估计(向上或向下)。如果任务估计最初是 6 小时，但团队发现必须完成更多工作并且该任务实际上需要 8 小时，则团队应相应地更新 Sprint 待办事项列表。如果有人花了 4 小时完成最初估计为 4 小时但仍需要 2 小时工作的任务，则应在 Sprint 待办列表中报告这 2 小时。如果团队发现必须完成但未确定的任务，则团队必须将此任务及其估计添加到 Sprint 待办事项列表中。一开始不准确也不是问题，只要你用随着时间的推移收集的知识更新积压工作。您越早进行这些更新，您就能越早适应和做出决定。
也就是说，保留“初始估计”并将其与“完成所花费的实际时间”进行比较是很有用的。但不是为了跟踪目的，只是为了帮助团队做出更好的估计。实际上，如果您要过渡到 Scrum，我建议不要这样做。当您学习 Scrum 值(value)观和原则时，通常还有许多其他障碍需要解决，许多其他事情需要首先改进。如果您这样做，请注意瀑布守护进程。准备好与他们战斗，他们可能会很快回来。
关于project-management - Scrum 中的时间跟踪，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1607214/