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


(info) 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:

Aggregate Hour Burndown Charts

An aggregate 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 Number of Hours

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

Unlike sprint hour burndown charts, the initial 'Number of Hours' values on aggregate 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 'Number of 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 'Number of 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.

Sprint periods usually occur back to back. However, it is possible for time gaps to occur between them. If work is logged outside the time period of any sprint, but during a valid date within the time period of its parent version, then that work log will be ignored in the parent version's aggregate hour burndown chart.

6 Comments

  1. Tom Moors

    Feb 15, 2011

    What is the motivation in ignoring the work spent between versions?

    When viewing a parent chart, I expect to see all the work done for this version. Is there a workaround to include these hours?

    1. Anonymous

      Feb 15, 2011

      Indeed, this doesn't make sense.  The JIRA panels next to the burndown charts show the correct values for time spent and the burndown charts should visualize these numbers.  I'm also curious concerning the motivation for changing this.

  2. Anonymous

    Feb 15, 2011

    One thing I would like to add to my previous comment: If you close a child version and a card is not closed yet, you are forced to move it to another version.  The result of this is that the original fixversion is removed and a new fixversion is added.  But this doesn't mean that greenhopper should ignore the fact that the hours were logged in the previous version.  And certainly not ignore them when you request a team effort for the parent version because the hours are logged perfectly fall in between the startdate and enddate of the parent version.

  3. Giles Gaskell

    Apr 13, 2011

    Hello there,

    The purpose of an aggregate hour burndown chart is to represent an aggregate of hours worked across a series of sprints (i.e. child versions), based on work logged within those sprints only.

    When following a typical Agile methodology, the 'timebox' periods of sprints are either back-to-back and/or work is logged on issues assigned to a sprint within that sprint's timebox period only.

    If work on any issue in a sprint cannot be completed within that sprint's timebox period, use GreenHopper's Release feature (as described in this comment) to move that issue to the next sprint. In doing so, any work logged on that issue in the previous 'released' sprint will still be recorded by GreenHopper and will be reflected in:

    • that released sprint's hour burndown chart +
    • the aggregate hour burndown chart.

    This will also apply to an issue moved across multiple sprints.

    Hope this information helps.

    If you would like GreenHopper aggregate hour burndown charts to account for work logged on a given sprint's issue outside of that sprint's timebox period, then I would recommend raising a feature request through the 'Report a Bug' button below. Doing so will allow people to vote on that issue to improve the chances of this feature being implemented in the product. Please also feel free to provide any reasons for this feature request too.

    Best regards,
    Giles.

  4. Thomas Haak

    Apr 10, 2012

    Hi,

    this comment is on the Remaining Estimates only. It took me quite a while to find this page and understand that hour burndown charts for parent versions in Jira are aggregating charts. I was always wondering why my "Time Remaining" in the burndown chart of a parent version was so much higher than the real remaining time that I have in my backlogs. Now, that article is quite clear on this: "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.". Unfortunately that is not what I want to see.

    As explained above, the issues that were not completed within a sprint (and therefore contributing to the "Time Remaining") will quite likely via the Release feature be moved to the next sprint, where they again quite likely will then be resolved (setting remaining time to 0). Therefore, at the end of a series of sprints the remaining time can only be the "Time Remaining" of the still open issues on the last sprint and not the accumulated "Time Remaining" from the ends of all child sprints.

    I'm now thinking about raising an issue or feature request. Or has anybody else a solution to this?

    Best regards,
    Thomas

  5. Steve Lane

    Jun 16, 2012

    I'm in the same boat as far as not understanding the intent here. Suppose I complete a sprint and have 10 hours of work remaining. I move the unfinished issues to the next sprint and add a number of new issues.

    I complete the issues from the previous sprint, and work on issues for the current sprint as well. At the end of sprint 2, 12 hours are remaining. The 10 hours from the previous sprint are most definitely not still "remaining" – I completed them. As Thomas Haak says, the hours remaining in the parent version now should be 12, not 22.

    I'm trying to steer my company toward using these tools, but issues like this make it unclear if we can do so.

    Can someone at Atlassian explain the logic of summing the Time Remaining in this fashion?



Log a request with our support team.



Raise an issue for our developers.



See answers from the community.



Tweet, blog and update our documentation.

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.