nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Starting point of Hour Burndown Chart changes

Joeri Moors

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

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

Accepted answers

All comments

OmarA

Hi Joeri,

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

Cheers,

Omar

Joeri Moors

Done.

Added two screenshots to visualize what I mean.

Renjith Pillai

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)

Joeri Moors

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

Renjith Pillai

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?

Joeri Moors

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

Renjith Pillai

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.

Eric Girard

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.

Joeri Moors

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software