Personally, I've never heard a single team member (besides the scrum master or manager) say that the burndown helps them in delivering features. That alone, to me means that in general the sprint burndown fails the smell test.
Ok, I’m just going to throw something out there. Do agile/scrum teams actually benefit from a burndown chart? I’m not talking about mangers, but the actual teams? I know I know, the sprint burndown chart is a well documented and proven method of evaluating the health of a sprint. And, in that respect, I agree. But if we’re talking about the teams themselves, is there a benefit to actually achieving the work?
Let’s poke around this idea a bit...
For one thing, at least on the surface, the burndown chart doesn’t pass the manager smell test. By that, I mean that it’s a manager-driven artifact of the sprint. Even after working for years with a multitude of agile and scrum teams at different companies, I have yet to see a single team who actively creates, maintains and examines the burndown. In my experience, it’s always the manager who asks the scrum master to show them the burndown. To me, anything that’s 100% manager-driven is inherently evil… evil! Yes, of course I'm being hyperbolic, but that statement is a surprisingly accurate heuristic :)
Next, in a true agile/scrum team, what does the burndown always look like? Well, I’ll tell you what 95% of the burndowns I’ve created look like. The trendline is flat for the first 1/4 - 1/2 of the sprint during the swarming, ideation, prototyping, and other boilerplate tasks. These are all attributes of a self organized and motivated team, but if we’re only looking at the burndown chart, it looks like the team is slacking off and not delivering. Hurry! Get some work to Done so our burndown will look good! (Yes, I’ll admit, I’ve said that myself after receiving pressure from managers to deliver)
Anything that’s 100% manager-driven is inherently evil… evil!
Lastly, don't let us forget that there is a scrum/kanban board where it is absolutely clear and apparent the status of all tasks and the health of the sprint. I’m of course making a few assumptions here. One is that all of the stories are small, achievable, and can be moved to Done by the end of the sprint. The next assumption, and this is the one I see teams fail at quite often, is that there aren’t 100+ stories on the board. One of the reasons the ideal scrum team is small (7 people +/- 2) is to ensure that every single person on the team knows exactly what each other person is working on. This is pretty easy to do with 7 people, but not with 17. The same goes for stories on the scrum board. Keeping the quantity of stories as low as possible ensures the team has a clear goal and deliverable. If you can’t visually scan the board in 2 seconds and assess the health of the sprint, there’s a chance you just have too many things on the board at once.
I'm not advacating that the burndown doesn't have its uses. For longer sprints, well defined projects and epics, the burndown chart can be helpful to see if a team is on track to hit the commitment. Hell, gantt charts are even useful sometimes! That being said, when is the last time you started a sprint with 90+% confidence that all the work is scoped? I for one almost never make it to lunch on Tuesday before something new has been discovered, or the business is changing course, rendering a long-term burndown essentially useless.
Being agile (among other things) is all about delivering value, that's it. Personally, I've never heard a single team member (besides the scrum master) say that the burndown helps them in delivering features. That alone to me means that in general the sprint burndown fails the smell test.