How Hour Burndown Charts Relate to Time Tracking in JIRA

On this page:

Overview

Scrum is a methodology that improves team communication and the incorporation of customer feedback during the development of a product's 'major version'. Typically in Scrum, the period of time required to development a major version is broken down into smaller time chunks known as 'sprints', each of which represents a tangible 'development milestone'.

When applying Scrum to GreenHopper, sprints have the following characteristics:

• A major version and its sprints are set up as versions in GreenHopper.
• Each sprint is typically a shorter period of time within its major version's time frame.
• Each sprint is a 'child' of a major version.
• A sprint has no child versions of its own.

In GreenHopper's implementation of Scrum, there are two types of hour burndown charts:

• Sprint hour burndown charts — show a timeline of the total work logged on the issues which belong to that sprint and changes to its issues' Remaining Estimate fields.
  
  
• Aggregate hour burndown charts — show a timeline of the total work logged on all issues that belong to a major version. This includes all issues belonging to the major version's sprints. In these charts, the time spent working on issues is aggregated together from all issues in the major version's sprints, across the entire period of that major version. For more information about child and descendent versions, please see the following information box.
  
  

  About nested child versions:

  
  GreenHopper allows you to nest child versions to provide flexibility in Scrum project management. For example, you might want to group all issues that need addressing in a major product version at the highest level of a version hierarchy. Since you might have separate teams, each working on different components that constitute this major product version, you may wish to represent each of those components as an immediate child ('component') version of the major product version. From here, you may wish to break up a given component into sprints, depending on the amount of work required to develop it. Therefore, each of these sprints would be an immediate child ('sprint') version of its respective 'component version'.

For more information about time tracking in JIRA and the relationship between logging work and time estimates, please refer to Logging Work on an Issue.

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 older Work Logs changes.

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
  
  
  
  
• Burndown chart 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 Remaining 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 enter this estimate into the issue's Original Estimate field, since JIRA automatically copies this value across to the Remaining Estimate field once the issue is created.

On a sprint hour burndown chart, the Burndown chart curve (green) and Guideline curve (red) have the same initial 'Remaining 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 'Remaining 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 'Remaining 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 remaining 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.
    
    

Older Work Log Changes

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 values of 'Remaining Hours' 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 Remaining Hours value of the green and red curves (at x=0) do not change. This is helpful in showing whether or not improvements in the accuracy of sprint planning estimates are required.

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 Remaining Hours value 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.

Aggregated Hour Burndown Charts

An aggregated hour burndown chart is generated for GreenHopper versions with one or more child versions. However, the logic in generating these charts is different to that of sprint hour burndown charts. For aggregated charts, the Remaining Estimates and Team Effort of each child version's sprint chart is summed and spread across the entire duration of the parent version's aggregated chart.

Initial Remaining Hours

The initial 'Remaining Hours' values (at x=0) of the Burndown chart curve (green) and Guideline curve (red) in an aggregated hour burndown chart are the sum of the initial 'Remaining Hours' of the respective green and red curves of its sprint charts.

Unlike sprint hour burndown charts, the initial 'Remaining Hours' values on aggregated hour burndown charts can vary, since it is common practice to perform sprint planning immediately before the sprint's start date (as the previous sprint is winding up).

After planning the first sprint, the initial 'Remaining Hours' values of the aggregate hour burndown chart's red and the green curves will match those of the first sprint, even if the start dates differ. Once the second sprint is planned, its initial values will be added to the aggregated chart's initial values. Hence, the starting points (x=0) of the red and green curves will move up.

Drawing changes

Example:

• After sprint planning on two sprints, the first of which starts on the 19th of July with 10 hours worth of estimated work and the second starting on the 22nd of July with 20 hours of work, the initial 'Remaining Hours' values of the sprint's aggregated chart is 30 hours. On the 20th of July, 5 hours of work are logged, which is reflected in the green curve on that date.