Scrum burns charts, can they go negative?

Question

I am working on a small Agile development team, which is part of a large, impenetrable thinking corporation. We currently practice Scrum, and sometimes we exceed our sprint commitments.

My question is, how do you handle burnout schedules when you exceed your sprint obligations? I can imagine two options:

• Extend the y axis in the negative direction and keep reading
• Add more cards / stories / work and increase the value of burning by this amount, burning when this work is completed.

The ultimate solution for my team is one that is clear to the business and adds real value to the developers. So far, none of these solutions have worked out perfectly.

Answer 1

In my opinion, burnout schedules cannot go negatively. If you have finished your work, you either continue to sit on your chairs without doing anything, which means that burnout will remain at zero.

If you really do something, then this should be added to the task list, which means that burning will increase, and then down again when you finish the tasks that you added to your workload.

A sprint in which the initial workload was completed before the end of the sprint should show a slight surge when new tasks (both individual tasks, such as fixing bugs, or other or one or more new user stories) were added again as soon as they became clear that there is more space.

However, if this often happens with your team, you seem to constantly underestimate your speed and should start with more tasks from the start. I'm not saying that it’s bad to be able to finish early and take on more tasks, but if this happens in many sprints, this is a sign that the team is not coping from the very beginning, either by accident or absolutely sure that they are not able to hold back the sprint.

If it is good with your product owner, so be it. If I were the owner of the product, and I would see that one team always finished early, I would try to get them to do more tasks from the very beginning. It may sound a little tougher than it should have sounded.

Answer 2

Burndowns shows the volume remaining under the obligation. If you add something to your commitment because you are overloading, you add it to the number that you write on the chart. As a result, the team that overloads will have a burn that goes to zero, and then hover there until the end of the time-box typed.

To show what you are really doing, consider a combustion scheme or a cumulative scheme.

EDIT

• Burn-downs show that the work remained to complete "something" (sprint, release, MMF / "Epic", etc.).
• Burn-ups shows the accumulation of "something" (earned value for the business, overcoming complexity, etc.).
• The aggregate flowcharts show that both + give you an idea of ​​the quality of your process.

Answer 3

When we add more elements to the sprint, we update the estimate of the remaining work to reflect this in the sprint burning table:

alt text http://www.movingsummit.co.uk/images/burndown_chart.JPG

But, as indicated in other answers, this shows that the evaluation of the rest of the work has changed, and not the reason (did we just overestimate the work or did we add work?), And not the accumulation of the work done. Perhaps this is not a problem.

To represent the accumulation of work performed, a burnout chart is more suitable (we use a burnout chart at the output level). Burnout from the workload allows you to imagine the progress of the work performed, as well as an increase or decrease in requirements (and how this affects the forecast for completion):

alt text http://www.movingsummit.co.uk/images/burnup_chart.JPG

Answer 4

The expansion of the Y axis allows everyone to understand that you are above and above the sprint goal. This is usually not a big problem, because you do not worry so much.

If this is becoming commonplace or if you are switching to a significant amount, something is wrong with your assessment process. You may be too cautious about the "impenetrable" side of the business. Try and bring everyone to the trip.

Answer 5

Expanding the Y axis below zero is a well-established practice for tracking output progress.

Sample scroll burnout diagram

On the linked image, you can see the graph of the burned-out screen - everything that is added to the release area goes beyond zero.

I would not recommend doing the same thing as in the sprint chart of burning. You just have to add a new job to the remaining job, and obviously your burnout will continue for some time. If you use a board to present your sprint burning chart, then it's a good idea to mark the place in time when you added new stories / requirements with the proper comment. Thus, it will be perfectly visible what happened and why your burnout has risen.

Answer 6

If you constantly refuse to burn, this indicates that you are constantly evaluating, thereby ending your work "too early". To fix this, start multiplying the score by a factor of less than 1 (i.e. 0.75, 3/4) (I forgot the correct term for this - is it "scaling"?). Do it for a sprint or three, see how it affects the result, it may take several iterations to get the right factor for each developer. This means that you can fit more into the regular sprint, and it should not end earlier.

Answer 7

I ask you to disagree here :-) Try to consider the following scenario: the team begins to work on the story and realizes that a certain work was not planned, and now they add tasks to complete this work. Burnout goes up, but not for good reason, in this case it is not a change in area, but a “wrong assessment”, which from the point of view of the team does not matter, because the message is still: “this is the amount of work that needs to be completed "

How about the product owner? How much do you want to report that you are overloaded? How important is it for the team to distinguish between the two cases and use them in retrospect to analyze how to improve the score next time, or to do more from the very beginning? A similar approach was used to determine an alternative burning schedule ( http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown ), so re-basing the chart and burning more down clearly show the increased volume, and burning may be the team that opened up new tasks while starting to work on a story somewhere in a sprint; -)

Ciao
ANdreaT