我在一个小型敏捷开发团队工作，该团队隶属于一家大型非敏捷思维公司。目前，我们在练习 Scrum，有时我们会超过我们的 sprint 承诺。
我的问题是，当您超出了冲刺承诺时，您如何处理燃尽图？我可以想到两个选择：
对于我的团队来说，最终的解决方案是对业务清晰且为开发人员增加真正价值的解决方案。到目前为止，这些解决方案都没有完美解决。
【问题讨论】：
标签： charts agile scrum agile-processes burndowncharts
在我看来，燃尽图不能变成负数。如果你完成了你的工作，你要么继续坐在椅子上什么都不做，这意味着燃尽将保持在零。
如果您确实做了某事，那么应该将其添加到您的任务列表中，这意味着当您完成添加到 sprint 工作量中的任务时，燃尽图会上升，然后再次下降。
在 sprint 结束之前完成原始工作负载的 sprint 应该会在新任务（单个任务，例如错误修复等，或者一个或多个新用户故事）再次添加时显示一个小峰值。显然还有更多空间。
但是，如果您的团队经常发生这种情况，您似乎总是低估了自己的速度，应该从一开始就开始致力于更多任务。我并不是说能够尽早完成并承担更多任务是一件坏事，但如果这种情况发生在很多 sprint 中，这表明团队从一开始就没有充分承诺，要么是偶然的，要么是故意的绝对确定他们不会在 sprint 中失败。
如果您的产品所有者同意，那就这样吧。如果我是产品负责人，我会看到一个团队总是提早完成，我会尝试让他们从一开始就承诺更多的任务。这听起来可能比预期听起来更刺耳。
【讨论】：
燃尽图显示承诺中剩余的范围。如果您因为超额交付而在承诺中添加某些内容，则将其添加到您在图表中记录的数字中。因此，一个过度交付的团队将有一个燃尽图，趋向于零，然后徘徊在那里直到图表时间盒结束。
要显示您真正交付的内容，请考虑使用燃尽图或累积流程图。
编辑
【讨论】：
当我们向 sprint 添加更多项目时，我们会更新剩余工作的估计以反映在 sprint 燃尽图上：
alt text http://www.movingsummit.co.uk/images/burndown_chart.JPG
但正如在其他答案中所指出的，这表明 对剩余工作的估计发生了变化，而不是原因（我们只是重新估计了工作还是我们添加了工作？）而不是所做工作的积累。不过，这可能不是问题。
为了表示已完成工作的累积，燃尽图更合适（我们在发布级别使用燃尽图）。对工作量的燃尽可以代表已完成工作的进度以及需求的增加或减少（以及这如何影响完成的预测）：
alt text http://www.movingsummit.co.uk/images/burnup_chart.JPG
【讨论】：
延伸 Y 轴让每个人都清楚地知道您正在超越冲刺目标。通常这不是什么大问题，因为你不会去那么多。
如果这种情况经常发生，或者如果您超出了很多，则说明您的估算过程有问题。也许您在处理业务的“非敏捷”方面过于谨慎。试着带大家一起去兜风。
【讨论】：
将燃尽图的 Y 轴扩展到零以下是跟踪发布进度的良好做法。
在链接图像上，您可以看到发布燃尽图 - 添加到发布范围的所有内容都超过零。
我不建议对 sprint 燃尽图做同样的事情。你应该简单地将新工作添加到剩余的工作中，显然你的燃尽图会增加一段时间。 如果您使用白板来展示您的 sprint 燃尽图，最好在您添加新故事/要求时及时标记该位置并附上适当的评论。这样一来，就可以完全清楚地看到发生了什么以及为什么你的燃尽了。
【讨论】：
如果你的燃尽点持续消极，这表明你经常高估，从而“过早”完成工作。为了解决这个问题，开始将估计值乘以小于 1 的因子（即 0.75, 3/4）（我忘记了正确的术语——它是“缩放”吗？）。这样做一到三个冲刺，看看它如何影响结果，可能需要几次迭代才能为每个开发人员获得正确的因素。这意味着您将能够在常规 sprint 中适应更多，并且不应提前结束。
【讨论】：
我不同意 :-) 尝试考虑以下场景：团队开始编写故事并意识到尚未计划一定数量的工作，现在他们添加任务来完成该工作。燃尽增加，但并非完全有充分的理由，在这种情况下不是范围变更，而是“错误估计”，从团队的角度来看没有任何区别，因为消息仍然是：“这是需要完成的工作量”。
产品负责人呢？你想表达多少你已经超额交付了？对于团队来说，区分这两种情况，并在回顾中使用它们来分析下一次如何改进估计，或者从一开始就承诺更多，对团队来说有多重要？类似的方法已用于定义替代燃尽图 (http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown)，因此重新设置图表的基础并进一步燃尽，清楚地显示范围扩大，燃尽可能是团队在开始工作时发现了新任务冲刺中某处的故事;-)
巧
安德烈
【讨论】：