Scrum burn down charts, can they go negative? [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

I work on a small Agile development team which is part of a large, non-agile thinking corporation. Currently, we practise Scrum and occasionally, we exceed our sprint commitment.

My question is, how do you handle burn down charts when you have exceeded your sprint commitment? I can think of two options:

Extend the y-axis in the negative direction and keep counting down
Add more cards/stories/work and have the burn down value increase by that amount, burning down when that work is finished.

The ultimate solution for my team is one which is clear to the busines开发者_JAVA百科s and adds real value for the developers. So far, neither of these solutions has worked out perfectly.

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

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

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.

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.

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 ;-)

Ciao
ANdreaT