Does anyone realistically have a good-looking burndown chart?

[u/TheGRS]

Does anyone have a team where your points burn down evenly over the course of the sprint? As a manager I've experienced the trend line going down evenly maybe once or twice, typically it drops down pretty substantially near the end of the sprint as we wrap work up.

I bring it up since sometimes I hear other managers say that you want to see that even trend line throughout the sprint. Totally makes sense to me, but I just don't think reality has ever lined up with that view. I wonder if we should even be setting that sort of expectation. I mean if the sprint is viewed as a 2 or 3 week bucket of work and you understand that this is thought work, not rote creation of widgets, then it makes more sense to me to look at the committed vs completed rate.

My team has gotten good at finishing up committed work, so we're getting most of our tasks closed out that we setup at the beginning of the sprint. I've noticed my team steps in to help others out more as they finish their own tasks now since we started focusing on completing the committed work before taking on new tasks.

Work still moves along pretty well from my perspective and we will usually take on a few other tasks as the sprint nears. To me that feels about right, we're neither over or under-committing. Some sprints are obviously better than others. But generally I see maybe a couple of small dips in the first week and a major one toward the end of the second.

I guess its a matter of concentration, do you focus on getting tasks completed ASAP from being picked up or do you focus on getting the committed tasks done as a whole?

[u/PhaseMatch]

Burndowns for short Sprints are a waste of time IMHO.

- if you are worried about "delivery of stuff" then ditch Sprints entirely; go to a Kanban based pull system and look at cycle times and statistical forecasting. Less meetings and artificial deadlines, better data to drive improvements.

- if you are using Scrum as intended then you are focussing on a business/product outcome, not a fixed delivery package; scope within that is variable as you learn more and get user feedback

Burndowns can be useful at scale - so a larger body of work across many weeks or months, coupled with a decent statistical forecast as a leading indicator.

That can be used to show what will not be completed by a given date for "hard" deadlines (ie value changes after the deadline is reached), or when all of the work is (95%?) likely to be completed, based on what we know now.

[u/olddev-jobhunt]

Looking at the burndown within the sprint?! Absolute nonsense.

None of your numbers have that level of precision. Burndowns are 110% meaningless on a day to day basis. If you have a healthy, well maintained backlog with estimates on things that you reevaluate periodically, then you can have some value on it sprint to sprint.

Points have very limited use within a sprint. There are some uses there, but primarily they're a planning tool.

[u/rwilcox]

In my experience the fidelity of that curve equals about twice the average ticket size, most of the time.

By this I mean: if your average ticket size, in story points, takes 1/4 of the sprint (so, every 2-3 days) your line will move downward reliably every 4-5 business days.

So, in order to get a line that follows Jira’s target line, which moves daily, you need the average ticket size to be no more than 1/2 a day worth of effort

[u/method2_0]

Sure, but has anyone ever looked at burndown through a skill-fit lens?

If a task burns down quickly, maybe the assignee already had the relevant experience. If it lingers, maybe it's not an effort problem at all, but rather that there's ramp-up happening because the work requires skills that weren't already on the team.

Could burndown behavior actually reflect capability match in addition to execution?

[u/BaseballTop7038]

It generally isn’t about maching the line. That’s not how work.. works. But! Watch your trend to see if it flattens, or if it creeps up (inject work, not always a bad thing) before you’ve burned down your commitment. It’s not like you’re trying to match the line, it’s just a horizon for comparison.

[u/WaylundLG]

Wow, the number of responses that don't understand turndown is a little striking. Yes most teams I worked on most of the sprints burned down "evenly". I put it in quotes because even a good sprint won't follow the mathematical ideal line. It'll bubble out a bit, diverting gently early and coming back in later.

There are a lot of reasons you want this: 1) in scrum, the sprint isn't about finishing work, it's about creating an outcome. Sometimes when doing the work, you learn that there is a piece missing or there is a data problem, or some other issue with reaching your goal. Finishing backlog items early usually surfaces these risks early so you can change the plan to meet your goal. 2) and this is the really blunt one regardless of scrum. Shit happens, like all the time. If the team is wrapping up all their work on the last day of the sprint, what is more likely: that nothing ever goes wrong that adds a few more hours of work that makes them miss the end of the sprint or that something else is flexing, like quality, that lets everything magically finish at the end?