我们已经使用 Scrum 大约 9 个月了，而且基本上是成功的。然而，我们的燃尽图很少看起来像“模型”图表，而更像是一个可怕的过山车，带有一些呕吐物引起的爬升和下降。
为了尝试解决这个问题，我们在 sprint 原型设计和设计之前花费了更多时间，但我们在 sprint 期间发现的工作似乎仍然比最初想象的要多得多。注意：我的意思是满足积压工作所需的工作比最初想象的要复杂得多，而不是我们已经确定了积压工作的新项目。
这是 Scrum 的一个常见问题吗？是否有人有任何提示可以帮助顺利进行？
我应该指出，我们的大部分开发工作都不是全新的，因此我们正在维护现有大型复杂应用程序的功能。Scrum 是否不太适合这种类型的开发仅仅是因为您不知道现有代码会抛出什么问题？
在 sprint 开始制定开发细节之前，我们应该花费多少时间？
更新：我们现在取得了更大的成功和更顺畅的旅程。这主要是因为我们在估计时采取了更加悲观的观点，这给了我们更多的喘息空间来处理没有按计划进行的事情。你可以说它让我们更加“敏捷”。我们还试图改变燃尽图是某种时间表而不是范围v资源指示的看法。
一些关于平滑事物的技巧。
1）正如其他人所说 - 尝试将任务分解成更小的块。更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励您与产品负责人交谈，看看您是否可以缩小范围或“精简”故事。我觉得后者更有效。如果团队和产品负责人都了解正在讨论的内容，那么兼顾优先级和估计会更容易。
我的一般经验法则是任何大于理想一天一半的估计都可能是错误的:-)
2）尝试做更短的冲刺。如果您正在进行一个月的冲刺 - 尝试两周。如果你做两周 - 尝试一个。
3）使用站立和回顾来更多地了解起起落落的原因。是在您花时间处理代码库的特定区域时吗？是民间对产品负责人的误解造成的吗？会占用团队开发时间的随机紧急情况？一旦你对起起落落的来源有了更多的了解，你通常可以专门解决这些问题。再一次 - 较短的冲刺可以帮助使这一点更加明显。
4）相信你的历史。你可能知道这个......但我还是会说 :-) 如果摆弄那个可怕的遗留 Foo 包所花费的时间比你认为它持续 sprint 的时间长 3 倍 - 那么它也需要 3 倍，只要你认为下一个冲刺。无论您认为这次会变得多么有效；-) 相信历史并使用昨天的天气之类的东西来指导您在明年春天的估计。
希望这可以帮助！
我很高兴听到 Scrum 对你来说基本上是成功的——这比让 sprint 燃尽图看起来很理想更重要。sprint 燃尽图只是团队的一个工具，可以帮助它了解它是否在实现 sprint 目标的轨道上。如果团队一直在实现冲刺目标，我不会太担心图表看起来像过山车。几点建议
如果您还没有达到 sprint 目标 - 使用既定的团队速度在下一个 sprint 期间承担更少的任务。你必须擅长走路才能跑步。
根据我的经验，Scrum 肯定更倾向于新的开发而不是维护。新的开发比维护一个旧的、大型的代码库更容易预测。
话虽如此，一个可能的问题是您没有将任务分解成足够小的块。总体而言，人们对软件规划的一个常见问题是他们认为“哦，这项任务应该花我 2 天时间”，而没有真正考虑过执行该任务的内容。通常，你会发现，如果你坐下来想一想，这项任务由做 A、B、C 和 D 组成，最终需要超过 2 天的工作时间。
正如其他人所说，我预计烧毁会上下波动。事情发生了！您应该使用“上下”部分作为回顾的素材。
确保每个人都清楚“正在完成”的含义，并利用这种共同理解来帮助推动您的计划会议。通常，列出可用的已完成内容的清单将（a）帮助您记住您可能忘记的事情，并且（b）可能会引发更多关于任务的想法，否则这些任务将在以后浮出水面。
要考虑的另一点 - 如果您每月都在使用不可预测的代码库工作，我仍然希望您的速度正常化到一个合理稳定的速度。只需根据计划的工作跟踪您的成功，并在计划时最大限度地使用已完成的项目。然后专注于你计划外的任务，看看是否有任何模式表明你可以做不同的事情来将这些事情包括在计划的工作中。
我有过类似的问题。我以前的团队（工作了一年多）很大，我们为一系列初始产品发布维护了一个非常大的、快速变化的代码库。我们的烧毁看起来很可耻，但这是我们能做的最好的。
可能有帮助的一件事（使您的图表看起来更好）是坚持不变的小时数/点数。如果您低估了一项任务，并且不得不加倍工作，请从 sprint 中抽出一些东西。如果你拉入一项新任务，它显然比你的团队承诺的事情具有更高的优先级，因此将其他事情拉出来。
我们尝试在计划中和计划之前将任务分解为许多任务，但这似乎没有帮助。事实上，它只是给了我们更多该死的票，以便在冲刺期间跟踪。需求开始迁移到票证上，并且（毫不奇怪）在所有的洗牌中迷失了方向。
在我的新团队中，我们采取了一种非常激进的方法，并开始创建大票（有些超过一周），上面写着“在 ProjectX 中实现 v1.2 功能”之类的内容。ProjectX 的需求/功能列表（包括 1.2 版）保存在 wiki 上，因此工单非常干净，只跟踪执行的工作。这对我们帮助很大——我们需要跟踪的工单要少得多，并且能够完成所有的 sprint，即使我们不断地完成我们的 sprint 任务来帮助其他团队或扑灭火灾。
当（且仅当）我们被迫（被人）引入新项目时，我们会继续将项目推出 sprint。
另一个对我们有帮助的简单提示：将“冲刺总小时数”添加到您的燃尽图。这应该是所有估计值的总和。努力保持这条线平坦可能会有所帮助，并增加您的团队可能面临的问题的可见性（假设这不会让您降级......）
-ab
我在燃尽时也遇到了类似的问题。我通过精炼包含在燃尽图中的内容来“修复”它。
SiKeep 评论说：
它针对为该 sprint 选择的积压工作取得了进展，这可能会也可能不会最终作为一个版本发布。
由于您为 sprint 选择了某些东西，而这就是燃尽图上的内容，我不知道所有“新工作”都应该出现在燃尽图中。我会看到它进入积压工作（不影响燃尽），除非它足够重要到进入你当前的冲刺（然后会在燃尽中显示为上升趋势）。
也就是说，如果趋势线基本上遵循您的预期速度，则小幅上涨和下跌是正常的。我会担心你提到的过山车趋势。但是，通过仅在当前 sprint 中添加高优先级项目来隔离燃尽的想法可能有助于抑制燃尽中的这些起伏。
正如其他人所说，冲刺开始之前的计划应该很短......（不超过4小时）。
我们正在为计划外的任务使用“限时”任务。每当高优先级的工作即将到来，或者突然出现错误时，我们都可以使用时间框的时间（但是，我们永远不能低于零）。这种方法还有一个额外的优势，即我们可以轻松跟踪哪些任务是不可预见的，并在我们的下一个 sprint 计划中将这些事情考虑在内。
您可以在 sprint 的开始日期整合新工作，以获得漂亮的燃尽图。
您可以使用特定标记标记额外的工作，并在 sprint 结束时评估您以前无法识别这些任务的原因。
我们现在使用燃尽图。我们不仅绘制了剩余的工作量图表，还绘制了两件事：已完成的工作量和总工作量（即已完成 + 未完成）。
这为您提供了图表上的两条线，当所有工作完成时它们应该相交。它还有一个很大的优势，因为它可以清楚地显示什么时候进展缓慢，因为增加了更多的工作。
如果您愿意，PO“拥有”一行（总工作），开发人员/测试人员“拥有”另一行（完成的工作）。
PO 的行会随着他们添加/删除工作而上升和下降。
开发/测试人员线只会在他们完成工作时上升。
这是应该的。如果您的燃尽图看起来像模型图，那么您就有麻烦了。该图表将有助于查看您是否能够做出承诺并完成所有故事。
在冲刺期间发现故事总会发生。理想情况下，您将能够预先设计并找出任务，但如果它们奏效了，为什么大型前期设计不起作用？回答你最后一个问题，冲刺计划最多需要四个小时。
