In my opinion, burndown charts can't go negative. If you're done with your work you either keep on sitting in your chairs doing nothing which means that the burndown will stay at zero.
If you indeed do something, then that should be added to your list of tasks, meaning that the burndown will go up and then down again when you're done with tasks you added to your sprint's workload.
A sprint where the original workload has been completed before the sprint ends should show a little spike when new tasks (either single tasks, e.g. bug fixes or whatever, or one or more new user stories) have been added again once it became clear that there's room for more.
However, if this happens frequently with your team you seem to be constantly underestimating your velocity and should start committing to more tasks from the beginning. I'm not saying that it's a bad thing to be able to finish early and take on more tasks, but if this happens in a lot of sprint it is a sign that the team is undercommitting right from start, either by accident or to make absolutely sure that there's no way they will fail the sprint.
If that's okay with your product owner, so be it. If I were the product owner and I would see one team always finishing early I would try to get them to commit to more tasks right from the start. This might sound a bit harsher than it's intended to sound.
Burndowns show scope remaining within a commitment. If you add something to your commitment because you are over-delivering, you add it to the number you are recording in the chart. As a result, a team that is over-delivering will have a burndown that heads toward zero and then hovers there until the end of the charted timebox.
To show what you are really delivering, consider a burn up or cumulative flow diagram instead.
EDIT
Burn-downs show work remaining to complete "something" (a sprint, a release, a MMF/"Epic," etc.)
Burn-ups show accumulation of "something" (earned business value, overcome complexity, etc.)
Cumulative flow diagrams show both + give you insight into the quality of your process
But as pointed out in other answers, this shows that the estimation of the remaining work changed, not the reason (did we just re-estimate the work or did we add work?) and not the accumulation of work done. This might not be an issue though.
To represent the accumulation of work done, a burnup chart is more appropriate (we use a burnup chart at the release level). A burnup against the workload allows to represent the progress of the work done and also an increase or decrease in requirements (and how this affects the forecast of completion):
Extending the Y-axis makes it really clear to everybody that you're going above and beyond the sprint goal. Usually it is not a big issue because you don't go that much over.
If it becomes a regular occurrence or if you go over by a significant amount there is something wrong with your estimation process. Perhaps you're overly cautious in dealing with the "non-agile" side of the business. Try and bring everybody along for the ride.
On linked image you can see release burndown chart - everything what is added to release scope goes beyond zero.
I wouldn't recommend doing the exact same thing to sprint burndown chart. You should simply add new work to remaining work and obviously your burndown will go up for a while. If you're using whiteboard for presenting your sprint burndown chart it is good idea to label the place in time when you added new stories/requirements with proper comment. That way it will be perfectly visible what happened and why your burndown went up.
If you are persistently going negative with your burn down, that would indicate that you are constantly over estimating, thus finishing your work "too early". To fix this, start to multiply the estimate by a factor of less than 1 (i.e. 0.75, 3/4) (i forget the correct term for this - is it "scaling"?). Do this for a sprint or three, see how it affects the outcome, it may take a couple of iterations to get the right factor for each developer. This means you will be able to fit more within the regular sprint and it shouldn't finish early.
I beg to disagree here :-) Try to consider the following scenario: The team starts to work on a story and realize that a certain amount of work has not been planned, and now they add tasks to complete that work. The burndown goes up, but not exactly for a good reason, in that case is not scope change, but is "wrong estimation", that from a team perspective doesn't make any difference, as the message is still: "this is the amount of work that needs to be completed".
What about the Product Owner? How much you want to communicate that you have over-delivered? How much is it important for the team to distinguish the two cases, and use them at the retrospective to analyze how to improve estimations next time, or commit to more from the beginning? A similar approach has been used to define the alternative burndown chart (http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown), so re-basing the chart and burning more down, clearly show an increased scope, and burning up might be the team discovered new tasks while starting to work on a story somewhere in the sprint ;-)
发布评论
评论（7）
在我看来，燃尽图不能变成负值。如果你完成了工作，你要么继续坐在椅子上什么都不做，这意味着燃尽率将保持在零。
如果你确实做了某件事，那么应该将其添加到你的任务列表中，这意味着当你完成添加到冲刺工作负载中的任务时，燃尽率会上升然后再次下降。
在冲刺结束之前完成原始工作负载的冲刺中，一旦明确存在新任务（无论是单个任务，例如错误修复或其他任务，还是一个或多个新用户故事），再次添加时应该会显示出一点峰值。还有更多空间。
然而，如果这种情况在您的团队中经常发生，您似乎总是低估自己的速度，应该从一开始就开始致力于更多的任务。我并不是说能够提前完成并承担更多任务是一件坏事，但如果这种情况发生在很多冲刺中，则表明团队从一开始就没有充分承诺，无论是偶然还是为了让绝对确定他们不可能在冲刺中失败。
如果您的产品负责人同意，那就这样吧。如果我是产品负责人，并且我会看到一个团队总是提前完成，我会尝试让他们从一开始就致力于更多的任务。这听起来可能比预期的听起来更刺耳。
In my opinion, burndown charts can't go negative. If you're done with your work you either keep on sitting in your chairs doing nothing which means that the burndown will stay at zero.
If you indeed do something, then that should be added to your list of tasks, meaning that the burndown will go up and then down again when you're done with tasks you added to your sprint's workload.
A sprint where the original workload has been completed before the sprint ends should show a little spike when new tasks (either single tasks, e.g. bug fixes or whatever, or one or more new user stories) have been added again once it became clear that there's room for more.
However, if this happens frequently with your team you seem to be constantly underestimating your velocity and should start committing to more tasks from the beginning. I'm not saying that it's a bad thing to be able to finish early and take on more tasks, but if this happens in a lot of sprint it is a sign that the team is undercommitting right from start, either by accident or to make absolutely sure that there's no way they will fail the sprint.
If that's okay with your product owner, so be it. If I were the product owner and I would see one team always finishing early I would try to get them to commit to more tasks right from the start. This might sound a bit harsher than it's intended to sound.
燃尽图显示承诺范围内剩余的范围。如果您因为超额交付而在承诺中添加了某些内容，则可以将其添加到图表中记录的数字中。结果，超额交付的团队的燃尽率将趋向于零，然后徘徊在那里，直到图表时间框结束。
为了显示您真正交付的内容，请考虑燃尽图或累积流程图。
编辑
Burndowns show scope remaining within a commitment. If you add something to your commitment because you are over-delivering, you add it to the number you are recording in the chart. As a result, a team that is over-delivering will have a burndown that heads toward zero and then hovers there until the end of the charted timebox.
To show what you are really delivering, consider a burn up or cumulative flow diagram instead.
EDIT
当我们向冲刺添加更多项目时，我们会更新剩余工作的估计，以将其反映在冲刺燃尽图上：
alt text http://www.movingsummit.co.uk/images/burndown_chart.JPG
但正如其他答案中指出的那样，这表明 对剩余工作的估计发生了变化，而不是原因（我们只是重新估计了工作还是添加了工作？），而不是已完成工作的积累。但这可能不是问题。
为了表示已完成工作的累积，燃耗图更合适（我们在发布级别使用燃耗图）。工作量燃耗可以代表已完成工作的进度以及需求的增加或减少（以及这如何影响完成的预测）：
替代文本 http://www.movingsummit.co.uk/images/burnup_chart.JPG
When we add more items to the sprint, we update the estimation of the remaining work to reflect that on the sprint burndown chart:
alt text http://www.movingsummit.co.uk/images/burndown_chart.JPG
But as pointed out in other answers, this shows that the estimation of the remaining work changed, not the reason (did we just re-estimate the work or did we add work?) and not the accumulation of work done. This might not be an issue though.
To represent the accumulation of work done, a burnup chart is more appropriate (we use a burnup chart at the release level). A burnup against the workload allows to represent the progress of the work done and also an increase or decrease in requirements (and how this affects the forecast of completion):
alt text http://www.movingsummit.co.uk/images/burnup_chart.JPG
延长 Y 轴可以让每个人都清楚地知道您正在超越冲刺目标。通常这不是一个大问题，因为你不会做太多的事情。
如果这种情况经常发生，或者超出了很大一部分，那么您的估算过程就会出现问题。也许您在处理业务的“非敏捷”方面过于谨慎。尝试带大家一起去旅行。
Extending the Y-axis makes it really clear to everybody that you're going above and beyond the sprint goal. Usually it is not a big issue because you don't go that much over.
If it becomes a regular occurrence or if you go over by a significant amount there is something wrong with your estimation process. Perhaps you're overly cautious in dealing with the "non-agile" side of the business. Try and bring everybody along for the ride.
将燃尽图的 Y 轴延伸到零以下是跟踪发布进度的既定做法。
示例发布燃尽图
可以看到发布燃尽图 - 添加到发布范围的所有内容都超过零。
我不建议对冲刺燃尽图做完全相同的事情。您应该简单地将新工作添加到剩余工作中，显然您的燃尽度会上升一段时间。
如果您使用白板来展示您的冲刺燃尽图，那么当您添加新故事/需求并添加适当的注释时，最好及时标记该位置。这样就可以清楚地看到发生了什么以及你的燃尽率上升的原因。
Extending burndown chart's Y-axis below zero is well established practice to track release progress.
Sample release burndown chart
On linked image you can see release burndown chart - everything what is added to release scope goes beyond zero.
I wouldn't recommend doing the exact same thing to sprint burndown chart. You should simply add new work to remaining work and obviously your burndown will go up for a while.
If you're using whiteboard for presenting your sprint burndown chart it is good idea to label the place in time when you added new stories/requirements with proper comment. That way it will be perfectly visible what happened and why your burndown went up.
如果你持续地对自己的倦怠感到消极，那就表明你不断地高估，从而“过早”地完成你的工作。要解决此问题，请开始将估计值乘以小于 1 的系数（即 0.75、3/4）（我忘记了正确的术语 - 是“缩放”吗？）。这样做一到三个冲刺，看看它如何影响结果，可能需要几次迭代才能为每个开发人员获得正确的因素。这意味着您将能够在常规冲刺中进行更多调整，并且不应提前完成。
If you are persistently going negative with your burn down, that would indicate that you are constantly over estimating, thus finishing your work "too early". To fix this, start to multiply the estimate by a factor of less than 1 (i.e. 0.75, 3/4) (i forget the correct term for this - is it "scaling"?). Do this for a sprint or three, see how it affects the outcome, it may take a couple of iterations to get the right factor for each developer. This means you will be able to fit more within the regular sprint and it shouldn't finish early.
我在此不敢苟同:-) 尝试考虑以下场景：团队开始处理一个故事，并意识到尚未计划一定量的工作，现在他们添加任务来完成该工作。燃尽率上升，但并不完全是出于充分的理由，在这种情况下不是范围变化，而是“错误的估计”，从团队的角度来看没有任何区别，因为信息仍然是：“这是需要完成的工作量”。
那么产品负责人呢？您想传达的信息是您已经超额交付了多少？对于团队来说，区分这两种情况，并在回顾时使用它们来分析下次如何改进估计，或者从一开始就做出更多承诺，有多重要？类似的方法已用于定义替代燃尽图 (http://www.mountaingoatsoftware.com /scrum/alt-releaseburndown），因此重新调整图表基础并燃烧更多，清楚地显示范围扩大，燃烧可能是团队在冲刺中的某个地方开始处理故事时发现了新任务;-)
再见
安德烈亚特
I beg to disagree here :-) Try to consider the following scenario: The team starts to work on a story and realize that a certain amount of work has not been planned, and now they add tasks to complete that work. The burndown goes up, but not exactly for a good reason, in that case is not scope change, but is "wrong estimation", that from a team perspective doesn't make any difference, as the message is still: "this is the amount of work that needs to be completed".
What about the Product Owner? How much you want to communicate that you have over-delivered? How much is it important for the team to distinguish the two cases, and use them at the retrospective to analyze how to improve estimations next time, or commit to more from the beginning? A similar approach has been used to define the alternative burndown chart (http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown), so re-basing the chart and burning more down, clearly show an increased scope, and burning up might be the team discovered new tasks while starting to work on a story somewhere in the sprint ;-)
Ciao
ANdreaT