我们刚开始在我的公司做的混战。我们花了一些时间用计划扑克来估计工作量，然后当详细的任务完成时，每个任务都有一次时间估计。估计时间对任务
我们的问题是，时间估计是经常错误的（通常是高估）。虽然我们都同意的努力，得到一个团队，以时间任务达成一致是非常困难 - 什么需要1人一个小时可以拿别人3小时。我们最终走到了中间的某个地方。
谁应该想出一个任务的时间估计和时会出现这种情况？
这只是我们需要更多的练习的东西，或者是我们做错了？
人们实际上做的工作估计所涉及的费用。如果您使用原始时间作为估算指标，那么敏捷方法会对此不满。你的团队应该使用抽象来估计成本，比如“分数”。您可以从每个点1小时的粗略基线开始，最少1分。然后开发人员可以做出原始估计需要花费多少时间。如果他们在几个小时或任何其他单位时间内交谈，就会打他们或手腕上的其他人。
的一点是，作为发展通过多次冲刺一起移动，项目经理可以通过调整团队提供的符合现实“点”时间估计 - 这甚至每个个人开发者来完成。随着项目的进展，参与者的估计会越来越好。因此，由于Sprints是一个迭代过程，所以时间估计会随着迭代次数的增加而提高。
这引出了另一个问题：你为什么要担心时间？时间基本上是瀑布模型的成本。在敏捷中，目标是将软件开发为VALUE而不是成本。使用的理由是，企业所有者，项目经理和创造者（开发人员）都可以抽象地看待它，这是一个抽象的比较基础。 （无偏的不同参与者对时间的文化，社会或心理感知），企业主可以在一个给定的冲刺看看可用点 - 并且知道可用的点 - 他们可以选择的功能，是最重要的。这总是一个艰难的决定，但再次，目标是发展价值和远离时间拳击或功能填充。
“谁应该想出一个任务的时间估计和时会出现这种情况？”取决于你如何运作你的团队。你是否让团队成员真正自我管理，因此在冲刺期间有人抓住任务时会分配任务？您可能需要继续根据团队中普通开发人员的能力来完成时间。您是否有团队领导将任务分配给在Sprint计划会议期间创建的人员？让分配的人估计完成任务的时间。
我同意从工作量估计去除时间是有点混乱。最大的问题是：你高估任务时间有什么关系？在冲刺结束时，团队是否会坐下4-5天无事可做？如果是这样，请转到产品负责人，并让她知道该团队想要将一个或两个小物品添加到Sprint中。你通常不添加东西正在进行的冲刺，但Scrum的是管理工作的一个框架，只要添加新项目的团队迹象了，也没有必要，不要让Scrum的工作，为你的团队...不要强迫你的团队为Scrum工作。
而且，你的问题似乎表明你的团队具有比正在计划什么更大的速度。如果2周的冲刺（10个工作日）为10的速度，但你的团队得到第7天的一切完成后，刚上来就下一个冲刺的故事点至11或12
想知道为什么我的答案被拒绝投票。 – 2016-11-10 21:36:10
感谢您的回答。我们正在使用TFS敏捷模板，并在PBI/Bug上努力工作，但单个任务有时间。所有的燃烧都是从时间开始的。这仅仅是微软模式的一个缩影吗？如果我们没有设定时间，我们不会刻意告诉我们该怎么走 – Greg 2012-02-23 19:28:14
正如ingyhere所说，您不应该使用原始时间进行估算 - 或者更好：不能使用时间作为成本值在Scrum中。解决你的问题：坚持存储的要点，但不要估计单个故事任务。如果你想创建你的burndown，计算任务并将故事点与任务数量分开 - 例如Story是8点，则你有4个任务，因此每个任务的值都是2个点。如果你在白天解决2个任务，你的燃烧将减少4个点。 – 2012-02-26 17:52:50
正如你所指出的那样，任务所用的时间取决于工作的人。但故事要点的想法是不依赖于人。该团队关注焦点。所以这些观点反映了团队需要付出多少努力来完成这个故事。只要对任务做同样的事情。如果你想估计每个任务的努力，只需使用故事点。然后，总和应该归结到相应故事的故事点。 – RaphMclee 2013-03-28 12:52:36