Sprint Hour Burndown Charts

Note that this page only applies if you are using the Classic Boards (which are no longer being actively developed; read more).

On this page:

Sprint Hour Burndown Charts

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.

What JIRA Data is Used?

When work is logged against a JIRA issue, JIRA:

• Creates both a Work Log entry and a matching History entry.
• Stores the Time Spent against that issue in the Work Log entry and adjusts the issue's Remaining Estimate in the matching History entry.

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:

• Team Effort curve (blue) — summing the Time Spent values of all issues in the sprint on a given date. These following screenshot shows where you can find the Work Log entries on a JIRA issue.
  
  Screenshot: Work Log entries on a JIRA issue
  
  
• Remaining Values curve (green) — summing the Remaining Estimate field's New Value in the latest Work Log History entry of all the sprint's issues on a given date. The following screenshot shows where you can identify this New Value on a JIRA issue.
  The latest Work Log History entry is used because more than one of these entries may exist on any given date.
  
  Screenshot: Work Log History entries on a JIRA issue
  
  The Remaining Estimate's New Value in the latest History entry is circled in the following screenshot.
  
  

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.

Sprint Planning and Initial Number of Hours

During a sprint's planning phase, the time estimates of issues associated with the sprint are established. For any given sprint, GreenHopper assumes that:

• Sprint planning is completed no later than the end of the sprint's start date, and

• 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:

• If no work is logged against the issue on the sprint's start date, the issue's initial Remaining Estimate is the latest recorded Remaining Estimate field's New Value on that date.
• If work is logged against the issue on the sprint's start date, the issue's initial Remaining Estimate is the last recorded Remaining Estimate field's New Value before its first Work Log entry (on that date).

x=0 represents the start date of work on a sprint after planning has been conducted but before work has been logged.

Example:

• The following sprint has an initial Remaining Estimate of 10 hours (worth of work to be done) on its start date. Later that day, 3 hours of work was logged against an issue. Hence, the green curve's:
  • Initial 'Number of Hours' (at x=0) is 10 hours (the issue's last recorded Remaining Estimate — New Value field before its first Work Log entry)
    and
  • The number of hours at the end of the sprint's first day (x=1) is 7 hours (the issue's Remaining Estimate — New Value field of its latest History entry). The value of this field, calculated by JIRA, is equal to 3 hours of logged work subtracted from the issue's Remaining Estimate of 10 hours.
    
    

Changes to Older Work Logs

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:

• Log Work at a later date, resulting in a 'backdated' Work Log,
• Change the Time Spent values of past Work Log entries on a JIRA issue, resulting in a 'time-edited' Work Log, or
• Delete a Work Log entry.

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.

Backdated and Time-Edited Work Logs

GreenHopper handles 'backdated' and 'time-edited' Work Logs on its Hour Burndown Chart curves in the following manner:

• Blue curve — no adjustments are required because the date of JIRA's Work Logs always match the date when the work was actually conducted.
• Green curve — because the values in this curve are obtained from JIRA issues' History entries, for each backdated or time-edited Work Log in the sprint, GreenHopper adjusts the 'Number of Hours' values on this curve between the date of the backdated/time-edited Work Log and the date of its matching History entry. The value of this adjustment is the difference between the New Value and Original Value of the Remaining Estimate field in that History entry.

Examples:

• Backdated Work Log scenario:
  • In the following sprint, 2 hours of work conducted on the 11th of August were logged against an issue on the 16th of August (excluding non-working days). Hence, GreenHopper takes the difference between the New Value and Original Value of the Remaining Estimate field in the History entry (dated the 16th of August) and adjusts the green curve back to the date of this History entry's matching Work Log (the 11th of August).

• Time-edited Work Log scenario:

  • 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.

Deleted Work Logs

GreenHopper handles 'deleted' Work Logs on its Hour Burndown Chart curves in the following manner:

• Blue curve — the 'deleted' Work Log's Time Spent value no longer contributes to the sum of the 'Number of Hours' on the date of the deleted Work Log.
• Green curve — GreenHopper cannot make corrections to the 'Number of Hours' for 'deleted' Work Logs because the Work Log entry is no longer available. In the absence of a Work Log entry, GreenHopper cannot determine the date of that deleted Work Log entry. Instead, these corrections are implemented on the date when these Work Logs were actually deleted.

Changing Remaining Estimates

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.

Example:

• In the following sprint, an issue was estimated with 10 hours at sprint start. On the 20th, the Remaining Estimate was changed to 5 hours, which is reflected in the green curve on that date.
  
  

Adding Issues

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.

Example:

• In the following sprint, an issue was given a Remaining Estimate of 10 hours during its planning phase. On the 20th of July, another issue with a Remaining Estimate of 6 hours was added to the sprint, which is reflected in the green curve on that date.