Starting point of Hour Burndown Chart changes


We are facing some strange behavior when using the “Hour Burndown Chart”. We setup a Sprint with 320 hours. It has a Start Date and an End Date. All tickets are estimated upfront.

When we start working on the spring the starting point on thy Y-axis is nicely set on 360 hours. But then after a few days, a week (no pattern here) the starting point just changes. It keeps on decreasing during the spring. From what I’ve read in the documentation this shouldn’t change. Once the Sprint is started it will set the value and it will remain there even if you add or remove tickets during the sprint.

In one sprint it dropped like 4 times. This gives a useless burndown chart.

Does anybody recognize this behavior? Are we doing something wrong?




<After +- 5 days>

These are old screenshots, they are unfortunatly not consistent but its the same project/Version you are looking at.

9 answers

Hi Joeri,

I'm still a bit unclear about this, can you please attach a screenshot for the burndown chart?




Added two screenshots to visualize what I mean.

You mean to say the 11th Sept has become, 12th Sept? Can you also paste the screenshot of the sprint in the Planning board with Version selected and the expanded (to see the start/end dates)

Hi Renjith,

No sorry for the bad screenshots. I updated better ones so you can see where the problem is occuring.

In the first screenshot the starting point on the Y-axis indicates 750 hours.

In the second screenshot the starting point indicates 515 hours.

So somehow I loose 235 hours. This shift happened almost every week.

Hope this explains a bit more the problem we're facing.


And you are sure that the OriginalEstimate values of the issues are not changing during the Sprint? And also that new issues are not getting added in the Sprint in that week?

Hi Renjith,

Thanks for your comment.

See following article:

If I understand it correctly the initial estimated remaining work will not change after start date. However this is the problem we seem to face.


Again, I would like to know the details of how you are updating the estimates during the sprint. Give screenshots too of the issue history of one issue which was updated during the sprint.

I've spent 3 days on trying to understand this chart (because it is not accurate at all) and mostly how it behaves. The starting point is equal to: Remaing Estimate + Time Spent. So at the beginning, Original estimate = Remaining Estimate. If the original estimate for a task was 20 hours and that you log works of only 10 hours to complete it, you will then need to change the remaining estimate to 0 prior to being able to change the status to completed (or every other options that put and end the a task). So now your starting point will drop by 10 hours as work log = 10 and remaining estimate = 0.

Hi Eric,

Thank you for your answer and time!

But I'm still confused. I don't think the analisys is correct. On the following link is stated the following:

As I understand this correct the Initial number of hours at start of the project (Start date) is the Remaining Estimate at that time substracted with any hours logged already before that time. It would not make sense to substract hours from the Initial number of hours. (see redmarked sentence)

The following sentence also states that changing worklogs doesn't affect the Initial number of hours:

As mentioned above, since GreenHopper assumes that the planning of a sprint is completed no later than its start date, the initial 'Number of Hours' values of the green and red curves (at x=0) do not change. This is done deliberately to indicate if the accuracy of time estimates needs improvement during the sprint planning phase.

So I'm still confusted about this.

Is it a bug?


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 29, 2019 in Jira Software

Transforming Jira Software projects for general project management purposes

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....

145 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you