Starting point of Hour Burndown Chart changes

Hi,

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?

Thanks

Joeri

<Startingpoint>

<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?

Cheers,

Omar

Done.

Added two screenshots to visualize what I mean.

0 votes
Renjith Pillai Community Champion Jan 02, 2013

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.

Joeri

0 votes
Renjith Pillai Community Champion Jan 04, 2013

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: https://confluence.atlassian.com/display/GH059/Sprint+Hour+Burndown+Charts

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.

Joeri

0 votes
Renjith Pillai Community Champion Jan 06, 2013

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 https://confluence.atlassian.com/display/GH059/Sprint+Hour+Burndown+Charts 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?

Thanks

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Thursday in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

810 views 5 17
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot