Hi Steve,
the data GreenHopper uses to calculate the start point for the red Guideline is the remaining estimate value from the change history that was valid on the start date.
We can't use the original estimate reliably, since issues can be carried over several sprints. Take an issue that had an original estimate in sprint 1 of 20h, then 10h were done in that sprint. During release, the incomplete issue is carried on to sprint 2. Now in the planning session for sprint 2, the issue still has an original estimate of 20h - that would be wrong for sprint 2, as there are only 10h left to do.
When the original estimate is set in JIRA, the remaining estimate is initially set to the same value. That value from the issue's change history is what GreenHopper picks up for the chart.
In the screenshot you provided, you can see that work has been logged on the sprint start date. This is a realistic case, since you could have your planning session in the morning and users logging work for the afternoon. What GreenHopper does is picking up the last remaining estimate value from the change history before the work was logged. That value is taken as planned estimate for the red Guideline. At the end of the day, the remaining estimate after work was logged is taken, in your example the datapoint at 27-Sep.
Please see http://confluence.atlassian.com/display/GH/How+Hour+Burndown+Charts+Relate+to+Time+Tracking+in+JIRA#HowHourBurndownChartsRelatetoTimeTrackinginJIRA-SprintPlanningandInitialRemainingHours for more detailed info on how the Hour Burndown Chart works behind the scenes.
Best regards,
Alex
Bug
Highest (View bug fix roadmap)
JSWSERVER-4417 Guideline end point at Version Start Date should respect corrections made to "Original Estimate" field.
Hi Steve,
the data GreenHopper uses to calculate the start point for the red Guideline is the remaining estimate value from the change history that was valid on the start date.
We can't use the original estimate reliably, since issues can be carried over several sprints. Take an issue that had an original estimate in sprint 1 of 20h, then 10h were done in that sprint. During release, the incomplete issue is carried on to sprint 2. Now in the planning session for sprint 2, the issue still has an original estimate of 20h - that would be wrong for sprint 2, as there are only 10h left to do.
When the original estimate is set in JIRA, the remaining estimate is initially set to the same value. That value from the issue's change history is what GreenHopper picks up for the chart.
In the screenshot you provided, you can see that work has been logged on the sprint start date. This is a realistic case, since you could have your planning session in the morning and users logging work for the afternoon. What GreenHopper does is picking up the last remaining estimate value from the change history before the work was logged. That value is taken as planned estimate for the red Guideline. At the end of the day, the remaining estimate after work was logged is taken, in your example the datapoint at 27-Sep.
Please see http://confluence.atlassian.com/display/GH/How+Hour+Burndown+Charts+Relate+to+Time+Tracking+in+JIRA#HowHourBurndownChartsRelatetoTimeTrackinginJIRA-SprintPlanningandInitialRemainingHours for more detailed info on how the Hour Burndown Chart works behind the scenes.
Best regards,
Alex