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.
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.
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.
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.
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?
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
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!
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