For a planned sprint, it is hard to see the Actual burn chart close to the Ideal even though the required amount of points have been met. Is there anything specific to keep in mind to achieve an almost ideal burn chart at the end of the sprint?

  • 1
    Why do you care about having the "ideal burn down chart", instead of focusing on ensuring that you are delivering the most value to stakeholders?
    – Thomas Owens
    Commented May 24, 2019 at 17:13
  • @ThomasOwens Curiosity for perfection
    – Ren
    Commented May 24, 2019 at 17:23
  • Again - why? What value does it add to you, the team, or the organization, to have a burn down chart that looks "ideal"? What do you hope to accomplish by trying to have an "idea" burn down chart?
    – Thomas Owens
    Commented May 24, 2019 at 17:26

2 Answers 2


The first thing to acknowledge is that the ideal line is ideal in the mathematical sense, not in the qualitative sense. In fact, if I ever saw a burndown that matched the ideal line, that would be a massive red flag for me.

That said, certain burndown profiles can be indicators of problems and we can look at those.

Risk: Work not completing until late in the sprint is risky. The longer I pile up work, the more likely it is that an unexpected event like an outage, weather, integration problem, etc pushes those 9.5 days of work over the line and out of the sprint.

Cover-ups: When we take on that level of risk, teams often work extra hours or push things into the next sprint "in the shadows" to make it look like the work was done. This reduces transparency and leads to a long list of other problems.

Cutting Corners: Another tactic for finishing everything on time is to cut corners. Planned automated testing doesn't get done or code review gets skipped. This comes back to haunt us in quality problems later.

Reenforced Silos: A frequent cause of work spanning the sprint is that all work is taken on at once. People take tasks for themselves and everyone works separately. This intuitively feels more efficient, but loads of research has shown that the opposite is true. You actually get more done by ganging up on work items.

Output focus over value focus: Just like the last one, splitting up tasks amongst people often leads to a focus on individuals getting tasks done rather than delivering value, which usually requires multiple people to coordinate on a single effort.

This are all possible issues that could be happening in the team when you see burndown charts far off of the ideal line. Not are certain. The burndown chart is just meant to trigger a conversation, not explain anything by itself.

So what can you do to improve it? Well, asking yourself if you're having any of the problems above can help. For example, if you worry about output over value, you can ask the product owner to only express needs from the user point of view. For example "I wish I didn't have to re-enter duplicate information each time I fill out this form." The team can rally around this problem and work together to implement the solution. This will have multiple people working on it for a few days, then it's done. A side effect is that having a sprint full of these will cause the burndown to reduce each time one of these needs is met.

Also, a lesson from Lean: small batch sizes. Break things up into small value deliveries. Scrum says we have to get to a releasable increment every sprint, but many experienced teams return to a releasable increment every few days or even more frequently. Small steps allow for more rapid pivots.

  • Thank you, i liked the last part about releasable increment every few days, never thought about it so assertively.
    – Ren
    Commented May 24, 2019 at 19:34

Some things that I have found to help are:

  • Smaller stories / tasks - the smaller they are, the easier it is to get them to done earlier in the sprint
  • Maintain high quality - bugs are the arch enemy of a smooth burndown
  • Automated regression tests - running automated regression tests in continuous integration usually reduces the number of bugs that get found towards the end of a sprint
  • Careful planning - try and avoid bottlenecks (particularly around testing)
  • Take less work in to the sprint - avoid over-packing the sprint so that the team rushes at the end
  • Reduce external dependencies - difficult to get a smooth burndown if you have to rely on work that is outside of your control
  • Avoid a waterfall sprint mindeset - get the team thinking in terms of work being completed in small chunks regularly throughout the sprint

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.