On this page:
This section explains what JIRA data is used in generating Sprint Hour Burndown Charts and how GreenHopper adjusts these charts to handle changes to older Work Logs.
When work is logged against a JIRA issue, JIRA:
Bear in mind that the date/time of a History entry matches that of when it was created. However, the date/time of a Work Log entry matches that of when the work was conducted.
For each date on a Sprint Hour Burndown Chart, the 'Number of Hours' (y-axis) values of the following curves are calculated as described:
The Remaining Estimate's Original Values and Worklog Ids are used when calculating changes to older Work Logs (below). If work has been logged against an issue, the Remaining Estimate's New Value is equal to its Original Value from the previous Work Log History entry.
For simplicity, the examples in the following sections refer to sprints associated with a single issue only. Of course, when multiple issues are associated with a sprint, the rules above for calculating the 'Number of Hours' of each date in the blue and green curves still apply.
During a sprint's planning phase, the time estimates of issues associated with the sprint are established. For any given sprint, GreenHopper assumes that:
Work can be logged against any of the sprint's issues during its start date.
When estimating the time of a new issue in a sprint, you would typically enter this estimate into the issue's Original Estimate or Remaining Estimate field. If a Remaining Estimate value is not specified, JIRA automatically copies the Original Estimate's value across to the Remaining Estimate field, once the issue is created.
Be aware that GreenHopper does not use JIRA's Original Estimate field values in Hour Burndown Chart calculations.
On a sprint hour burndown chart, the Remaining Values curve (green) and Guideline curve (red) have the same initial 'Number of Hours' value (at x=0). For planning reasons, it is important that these values do not change after the sprint's start date.
The initial 'Number of Hours' of the green and red curves is the sum of the initial Remaining Estimate of all issues in the sprint. The initial Remaining Estimate for a sprint's issue is based on the following criteria:
x=0 represents the start date of work on a sprint after planning has been conducted but before work has been logged.
When work is logged against a sprint's issues on the actual days the work was conducted throughout the sprint's period, GreenHopper adjusts the green and blue curves accordingly.
However, JIRA permits the adjustment of older Work Logs too. A user can:
Because each Work Log entry in an issue has a matching History entry, GreenHopper identifies 'backdated' and 'time-edited' Work Logs by determining if the Work Log entry's date precedes the date of its History entry.
GreenHopper handles 'backdated' and 'time-edited' Work Logs on its Hour Burndown Chart curves in the following manner:
In the following sprint, 1 hour was initially logged against an issue on the 11th of August. On the 16th of August, the same Work Log was edited and its Time Spent value was changed to 2 hours. Hence, GreenHopper takes the difference between the New Value and Original Value of the Remaining Estimate field in the Work Log's History entry (dated the 16th of August) and adjusts the green curve back to the date of this History entry's Work Log (the 11th of August).
In this example, the net result is that the green curve changes inversely with respect to the blue curve. Be aware that this inverse relationship is unlikely to apply when two or more issues are associated with a sprint.
GreenHopper tracks changes to a Work Log entry using the entry's Worklog Id. Hence, if the a Work Log entry's Time Spent value is edited multiple times on a given date, GreenHopper adjusts the 'Number of Hours' values on the green curve between the date of this Work Log and the date when this Work Log entry's Time Spent edits were actually conducted. The value of this adjustment is the sum of all these Time Spent edits.
GreenHopper handles 'deleted' Work Logs on its Hour Burndown Chart curves in the following manner:
It is possible to change the Remaining Estimate of any issue in a sprint after its start date, without logging work. These changes will be reflected on the green curve on the date they were made.
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.
It is also possible to add new issues to a sprint or to add time estimates to existing issues after the sprint's start date. These changes will be reflected on the green curve on the date they were made.
Again, since GreenHopper assumes that the planning of a sprint is completed no later than its start date, the 'Number of Hours' values of the green and red curve at x=0 do not change. This is helpful in showing scope creep throughout a sprint.