我们已经使用Scrum大约9个月了，并且在很大程度上已经取得了成功。但是，我们的燃尽图很少看起来像"模型"图，而是更像是一个令人恐惧的过山车，伴随着呕吐物引起的爬升和下降。

为了解决这个问题，我们在进行Sprint原型设计和设计之前花了更多的时间，但在Sprint期间我们仍然发现比最初想象的要多的工作。注意：我的意思是，准备积压所需的工作要比首先想到的要复杂得多，而不是为积压确定新的项目。

这是Scrum的普遍问题吗，有没有人有任何技巧可以顺利驾车？

我应该指出，我们的大多数开发工作都不是未开发的项目，因此我们在现有的大型复杂应用程序中维护功能。 Scrum是否仅因为我们不知道现有代码将引发哪些问题而不太适合这种类型的开发？

在sprint开始制定开发细节之前，我们应该花多少时间？

更新：我们现在获得了更多的成功，并且行驶更加顺畅。这主要是因为我们在估计时采取了更为悲观的观点，这为我们在事情没有计划时处理事情提供了更多的喘息空间。我们可以说它使我们更加"敏捷"。我们还试图改变这种看法，即燃尽图是某种时间表，而不是范围v资源的指示。

解决方案

我们可以在sprint的开始日期集成新工作，以获得美观​​的Burndown图表。

我们可以使用特定的标记标记其他工作，并在sprint结束时评估为什么以前无法识别这些任务。

这是应该的。如果燃尽图看起来像模型图，那么我们就有麻烦了。图表将确定我们是否能够做出承诺并完成所有故事。

在冲刺期间发现故事总是会发生的。理想情况下，我们将能够设计并找出预先的任务，但是如果它们起作用，那么为什么大的前期设计不起作用？
为了回答最后一个问题，冲刺计划最多需要四个小时。

正如其他人所说，我希望燃眉之急会越来越大。东西发生了！我们应该将"上下"位用作回顾的基础。

确保每个人都清楚"完成"是什么意思，并使用这种共同的理解来帮助推动计划会议。通常，列出可以完成的工作将(a)记住我们可能忘记的事情，并且(b)可能会为以后会出现的任务引发更多想法。

还有一点要考虑，如果我们每个月使用不可预测的代码库工作，我仍然希望速度正常化到一个合理的稳定水平。只需对照计划的工作跟踪成功，并在计划时最多使用已完成的项目即可。然后专注于计划外任务，看看是否有任何模式表明我们可以做一些不同的事情以将这些事情包括在计划工作中。

以我的经验，Scrum肯定更着眼于新开发而不是维护。新开发比维护旧的大型代码库更可预测。

话虽如此，一个可能的问题是我们没有将任务分解成足够小的块。人们通常对软件规划存在一个普遍的问题，就是他们认为"哦，这项任务需要我两天时间"，而没有真正考虑执行该任务的内容。通常，我们会发现，如果我们坐下来考虑一下，该任务将包括A，B，C和D的工作，并且最终需要花费超过2天的时间。

我有类似的问题。我以前的团队(工作了一年多)很大，我们为一系列的初始产品发布维护了非常庞大，快速变化的代码库。我们的倦怠看上去可耻，但这是我们有史以来最好的。

可能有助于(使图形看起来更好)的一件事是坚持承诺的小时/点数。如果我们低估了一项任务，并且必须加倍工作，请从冲刺中抽出一些东西。如果我们执行一项新任务，那么显然它比团队致力于将其他任务撤出的任务具有更高的优先级。

我们试图在计划内和计划之前将任务分解为许多任务，但这似乎无济于事。实际上，这只是给我们提供了更多该死的门票，以便在冲刺期间进行跟踪。需求开始转移到票证上，(毫不奇怪)在所有的洗牌中迷失了。

在我的新团队中，我们采取了一种非常激进的方法，并开始创建大票(大约一周之久)，上面写着" ProjectX中的v1.2功能实现"。 ProjectX(包括1.2版)的要求/功能列表保存在Wiki上，因此票证非常干净，仅跟踪已执行的工作。这为我们提供了很多帮助，尽管我们不断摆脱冲刺任务来帮助其他团队或者扑灭大火，但我们可以减少门票记录的方式，并且能够完成所有冲刺。

当(且仅当)我们(被男人)强迫携带新物品时，我们继续将物品从冲刺中推出。

另一个对我们有帮助的简单提示：在工作量中增加"总的冲刺时间"。这应该是所有估计的总和。保持这条线的平坦可能会有所帮助，并增加团队可能面临的问题的可见性(假设这不会使我们降级……)

-ab

我的燃尽也有类似的问题。我通过细化燃尽中包括的内容来"修复"它。

SiKeep评论：

Its progress against the backlog
  selected for that sprint, which may or
  may not end up as a release.

既然我们为sprint选择了某些东西，那就是燃尽中的事情，所以我不知道所有"新工作"都应该出现在燃尽中。我会看到它进入了待办事项列表(不影响燃尽)，除非它足够重要以进入我们当前的冲刺(然后会在燃尽中显示为上升趋势)。

也就是说，如果趋势线基本上遵循预期速度，则小幅的上下波动是正常的。我会担心我们提到的过山车趋势。但是，仅通过向当前sprint添加高优先级项来隔离燃尽的想法可能有助于减轻燃尽的这些起伏。

正如其他人所说，在开始冲刺之前的计划应该很短(不超过4个小时)。

一些使事情变得顺利的技巧。

1)正如其他人所说，尝试将任务分解为较小的块。更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励我们与产品负责人交谈，看看我们是否可以缩小范围或者"简化"故事。我发现后者更有效。如果团队和产品负责人都了解正在讨论的内容，那么轻而易举地调整优先级和估算就更容易了。

我的一般经验法则是，任何估计值大于理想天数的一半都可能是错误的:-)

2)尝试做短距离的冲刺。如果我们要进行一个月的冲刺，请尝试两个星期。如果我们要做两个星期，请尝试一个。

• 它限制了故事的大小-鼓励产品所有者和团队处理更容易准确估算的较小故事
• 我们会更频繁地收到有关估算的反馈-而且更容易查看在冲刺开始时做出的决策与实际发生的事情之间的联系
• 通过实践一切都会变得更好:-)

3)运用站立和回顾的方式，多分析起伏的原因。是我们花时间在代码库的特定区域上吗？是因为人们误解了产品所有者吗？随机的紧急情况使开发人员远离了团队？一旦我们对起伏的根源有了更深入的了解，我们通常可以专门解决这些问题。较短的sprint可以使这一点更加明显。

4)相信你的历史。我们可能知道这一点...但是无论如何我都会说:-)如果摆弄那个可怕的传统Foo包比我们认为的最后一次冲刺花费了3倍多的时间，那么只要我们认为这会花费3倍下一个冲刺。不管我们认为这次效率如何；-)相信历史，并使用"昨天的天气"之类的东西来指导我们明年春季的估算。

希望这可以帮助！

我很高兴听到Scrum在我们看来已经取得了很大的成功，这比使Sprint精简图表看起来理想更重要。冲刺燃尽只是团队的一种工具，可以帮助团队了解冲刺目标是否正在按计划进行。如果团队一直在达到冲刺目标，那么我不会太担心图表看起来像过山车。一些建议

• 在sprint回顾期间，请问团队其他工作来自何处
• 冲刺初期没有良好的验收测试可能会导致额外的工作
• 没有积压的积压可能会导致额外的工作。一个好的经验法则是至少花费团队时间的5％来提前考虑下一个冲刺的故事。
• 监控进行中的工作-团队是否同时进行过多工作？
• 在sprint计划期间-团队对构成故事的任务的分解感觉如何？

如果我们尚未达到冲刺目标，请使用已建立的团队速度降低下一次冲刺的速度。跑步之前，我们必须先走路。

我们正在将"计划时间"任务用于计划外任务。每当需要进行高优先级的工作或者突然出现错误时，我们都可以使用时间范围内的时间(但是，我们永远都不能低于零)。
这种方法的另一个优点是，我们可以轻松地跟踪哪些未预见的任务，并在我们的下一个冲刺计划中将这些事情考虑在内。