Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

How Hour Burndown Charts Relate to Time Tracking in JIRA

Created by Giles Gaskell, last updated by Rosie Jameson [Atlassian] on Apr 09, 2013 2 minute read

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

概要

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 develop a major version is broken down into smaller time chunks known as 'sprints', each of which represents a tangible 'development milestone'.

When using Scrum on the Classic boards, 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.
Time-tracking statistics and charts are calculated per sprint, using the sprint's Start Date and End Date.

About nested child versions:

GreenHopper Classic 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'.

About time-tracking on the Classic boards

Note that the time-tracking statistics and charts in GreenHopper are different from JIRA. JIRA time-tracking is calculated per issue, regardless of Fix Version. The JIRA Time-Tracking report is calculated using the Fix Version, regardless of the GreenHopper Start Date and End Date. 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.

In the GreenHopper (Classic) 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 those 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.

ラベルなし

15 Comments

Anonymous
Sep 01, 2010
Hi,

How does the hour burndown graph deal with issues/tasks that are worked on over multiple sprints ie: work logged against an issue/task in sprint 2 as well as sprint 3? Does the work logged on this task during sprint 2 reflect in the sprint 3 burndown chart?

Andrew
1. Giles Gaskell
  Sep 06, 2010
  Hi Andrew,
  
  For hour burndown charts to properly handle all work logged against an issue which might move across multiple sprints (for example, sprint 1, 2 and 3), then use GreenHopper's Release feature when a sprint's period is over.
  
  Hence, if an issue in 'sprint 1' (for example) is not done, the Releasing: sprint 1 dialog box will indicate this and you can move that issue (plus any others which are not done) into sprint 2.
  
  Tip: You can access the Release feature from the Actions menu 'cog' icon next to a sprint version in the 'Statistics Column' of the Planning Board, Chart Board or relatively recently via the Task Board's done column.
  
  By using the Release feature, GreenHopper will respect all work logged against an issue throughout all the sprints which that issue has been present in.
  1. Anonymous
    Sep 03, 2010
    Great - thanks for your help on this Giles.
Anders Thörnström
Oct 13, 2010
We experience a problem when removing issues in the middle of a sprint, sometimes an issue is "blocked" by some reason and we need to remove it and add another one, the problem is that the removed issues time is removed from the sprints original time but the issue that we add (with the new features) adds time in mid sprint. how can we handle this ?

Thanks!
1. Giles Gaskell
  Aug 29, 2011
  Hello Anders,
  
  Apologies for the delayed reply. Here's a response from Alexander Hennecke (one of our GreenHopper Developers) regarding your query:
  
  This is the intended behaviour. It's called "scope change"... when you add issues in the middle of the sprint, their estimates should not be added to the start estimates. The planning values are what the team committed on when doing the planning session and should be stable. We're doing quite some work to actually achieve this
  
  The only workaround I could possibly see would be to log 1 minute of work backdated on the start day. That would trigger GH to try and work out the remaining estimate before that worklog, and since there is none, fall back to the original estimate value. Haven't tried that though.
  
  If you wish to discuss this query further, please try the 'answers' link at the end of this page.
  
  Cheers,
  Giles.
  1. Anonymous
    May 05, 2011
    This only answers the second part of the question. The first part, 'sometimes an issue is "blocked" by some reason and we need to remove it' is a problem still. When the issue is removed (e.g. moved out to a future sprint) then any work already done on that issue is no longer counted against the current sprint. Its a bit like the problem addressed using the 'Release' feature discussed above, but the current Sprint is not yet finished so using 'Release' is inappropriate.
  2. Jan De Geeter
    Aug 26, 2011
    Hello Giles,
    
    I am currently evaluating the purchase of Greenhopper 5.7, but I am not satisfied with how it generates burndown charts when the scope changes in the course of the sprint.
    
    I support the attitude of Greenhopper towards scope changes (see above): what a team commits to in the beginning of the sprint should not change once the sprint has started. Greenhopper does this right when you create a new issue, and add it to the sprint. But Greenhopper breaks this promise when you remove an issue from the sprint after the sprint has started. This issue completely disappears from the chart, also for datapoints in the past!
    
    Data points in the burndown chart that are in the past should never change. A team is taking a commitment not only on the first day, but on every day of the sprint. So whatever changes to the scope (adding new issues, bringing in existing issues by changing the version, or removing issues by changing the version), past datapoints should remain unchanged.
    
    So I do not really understand the logic behind Greenhopper right now. Can you clarify please?
    
    Thanks.
    1. Alex Hennecke
      Aug 30, 2011
      
      Hello Jan,
      
      we're aware of this shortcoming in the scope change. The reason is a technical one: Sprints in GreenHopper are implemented using JIRA versions, and the statistics and charts are based on the issues that are part of the corresponding version. If an issue moves out or is deleted, it's no longer associated with the version / sprint and in turn not included in the respective query result.
      
      Scope related issues are currently tracked at https://jira.atlassian.com/browse/GHS-1815 and https://jira.atlassian.com/browse/GHS-1288. We'll be revisiting the hour burndown charts when we add Scrum support to the Rapid Board, which is currently a labs feature in 5.7, and we'll be taking these things into account, so please feel free to add comments and vote for the respective issues.
      
      Cheers,
      Alex
Vivek
Oct 28, 2010
What happens when we edit the Original Estimate field value? I have seen that it is editing the initial number of hours (at x=0) for the sprint rather than changing the Remaining hours value for the date when the issue was created. I have checked both increasing and decreasing the Original Estimate of an issue which was created mid way during the sprint and it changes the x-0 Remaining hours for the Sprint in the Hour burndown chart.

Can this be prevented?
1. Giles Gaskell
  Jan 31, 2011
  Hi Vivek,
  
  Apologies for the delayed reply. Here's Alexander's response to your query:
  
  This is kind of the inverse case of the one above. The only situation when the original estimate field could actually influence the initial value is if there is work logged on the start date before any estimates were made.
  
  Are you logging work on the start date before specifying time estimates on any issues in your sprints? To avoid this issue, try to ensure you specify time estimates on all issues before logging work on them.
  
  If you wish to discuss this query further, please try the forums (via the link at the end of this page).
  
  Cheers,
  Giles.
  1. Anonymous
    Oct 12, 2011
    I have a similar issue where we log work on stories / tasks before they are all estimated. Hence the chart only reflects the burndown against issues that have been estimated instead of reflecting against the original estimates when they are available. I understand that it is useful to prevent original estimates from being altered but there shoudl be an admin option to allow these be reset if a user mistake or other such reason is the cause of this.
Anonymous
May 18, 2011
Our team is looking to switch to GreenHopper because it appears to integrate better with JIRA. Is it

possible to extract hours spent on all tasks in a given sprint? We need to report out to our customer.
1. Nicholas Muldoon [Atlassian]
  May 18, 2011
  Yes, there is an Excel export option available for the chart data on the hour burndown chart. You may also be interested in the time tracking analysis.
  
  Thanks,
  Nicholas
  1. Anonymous
    May 19, 2011
    Thanks!
Pat Pigatti
Feb 02, 2012
Hi,
we are currently on 5.7.2 and are soon to be upgrading to 5.8.6. if a task is being closed that still has a non-zero "remaining estimate" - could those remaining hours be zeroed out from the burndown chart calculation/views? Or maybe the burndown should exclude closed tickets? Maybe this is not an issue with 5.8. We discovered in this sprint that our burndown had far too many hours in it. The reason was because we had to move stories from previous sprints to this sprint becasue they still had unfinished tasks. But they also had closed tasks that still had "remaining estimate" hours - those hours were being included in our burndown. Please advise. Thanks in advance.