Tips for achieving ideal burn chart

Question

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?

Answer 1

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.

Answer 2

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