Burndown chart is overreporting work left

[Jason Fedelem]

We've traditionally been a Kanban shop, and for a number of reasons are switching over to using Sprints now.  I've created a dashboard showing our sprint burndowns, among other things.  We've reached the end of Sprint 1, and the burndown chart shows over 30 SP remaining, but the board and filter, which are accurate, show 16:

I've had to redact some info, but there are 23 cards in the Sprint.  All but 4 are done, which are the 4 shown in the bottom, mostly redacted, portion of the screenshot.

However, if you look at the "Remaining" line on the above chart, its showing about double that.

All of the other cards are in "green" statuses, meaning they are counted as "Done".

Thanks for any help you can provide.

[Nic Brough -Adaptavist-]

So your red line looks rather dysfunctional, and I think that might be feeding into your counting problems.

 For the first half-ish of the sprint, nothing happens, then suddenly, you get a hefty burn down.  That is absolutely fine and very very common.  Whilst the guideline says "we should be completing X points per day", in reality your developers are going to pick up a handful of tasks at the beginning of the sprint and not complete them on the first day.  It is perfectly normal to see a flat line for the first couple of days, while people are working on, but not completing, stories.

The bit that looks broken to me is the up-ticks.  A burndown should be a set of downward steps.  If the line goes up, that means you are either increasing the estimates on issues in the sprint, or adding more into the sprint.  Both of those represent scope-creep and you should not be doing them.  The burndown screams to me that you had some incident on the 27th and drew "fix incident" into the developers list of stuff to do.  Not great, but a perfectly valid thing to do, and explain in your sprint review.  I'm more worried about the little upward jags - they should not be happening at all.

Anyway, there are two things to look at to try to explain your burndown.  First is the scope creep I've talked about above, but the other one is far more simple to investigate - have you put sprint estimates on any sub-tasks?

[Jason Fedelem]

Everything you say is true.  Part of it is the growing pains of doing sprints for the first time, part of it is scope creep for business reasons I can't control.

However, that's not really my question.  My question is that we have around 16 SP left (see report on bottom), but the burndown chart is showing over 30 SP.

The burndown chart doesn't let me peek under the hood to see how its coming up with those lines, and digging thru the data hasn't explained it to me.  At this point I can't trust the burndown chart because it doesn't seem to match the underlying data. Just trying to figure that out.

[Nic Brough -Adaptavist-]

The burndown isn't as complex to work out as it looks.

Your board has a setting for "estimation" which tells it which numeric field you want to use for the sprint estimate.  It doesn't actually matter exactly what this field is - story points are a simple number, business value also, and if you've set it to the time estimates, it's just working with large numbers of seconds.

When you start a sprint, Jira adds up all the estimates on all the stories you've said you would do in the sprint (not sub-tasks - they are not sprint items).  That's the starting number at the top left of the chart.

• A downward step is made whenever you mark an issue as done.  The size of it is just the estimate on that issue.  
• An upward step is made if you add new things into the sprint, or re-open a done item.
• Both up and down steps can be made if you change the estimates on issues in the sprint.  You should not do that, it makes nonsense of sprints.  If you want to record how much you actually do on an issue, that's fine, it can help inform your estimates in the future, but don't change the estimate on items after starting a sprint with them in.

That's pretty much it. The upward jigs you are seeing in your burndown are due to changed estimates, scope creep and/or re-opening stuff.  The downward drops are because you're getting stuff done.

[Jason Fedelem]

Thanks for the reply.  I totally get that. 

However, if you look at the final red line value its a bit north of 30...say 33.  In the bottom part of the screenshot it shows that we actually have 16 SP left.  Shouldn't those numbers be the same?

[Nic Brough -Adaptavist-]

They probably should be the same number, but we can't tell you where it might be going wrong without seeing the raw data.

How is your board configured and what are the estimate on each issue?  (Sorry, quite blunt, but I wanted to keep the sentence short-ish)