Search the GreenHopper 5.8.x Documentation:

Index
Downloads (PDF, HTML & XML formats)
Other versions

This documentation relates to GreenHopper 5.8.x.
If you are using an earlier version, please view the previous versions of the GreenHopper documentation and select the relevant version.
Skip to end of metadata
Go to start of metadata

To view the hour burndown chart for your project version,

  1. Log into JIRA.
  2. Click the 'Agile' link's down-arrow in the top navigation bar and select 'Chart Board' from the resulting dropdown menu. The 'Chart Board' will be displayed.
  3. Select your project from the project dropdown (top left of the chart board above the 'Chart Board' dropdown), if it is not already selected. The 'Chart Board' will refresh with information for your project.
  4. Using the Chart Board Navigation Bar, select the version whose chart you wish to view in the Version dropdown, then select 'Hour Burndown Chart' from the dropdown menu next to it. The hour burndown chart for the version will be displayed (see screenshot below).
    • The 'View Version' dropdown only includes versions which contain issues that belong to at least one unreleased Fix Version (and belong to a project that is GreenHopper-enabled).
    • The chart's 'Start Date' and 'End Date' are the Fix Version's dates defined on your Planning Board. If not defined on your Planning Board, the 'End Date' is the 'Release Date' defined in the JIRA version; or today's date, if not defined in JIRA.
    • You can toggle items in the chart on and off, by selecting or clearing their check boxes in the legend under the chart.
    • You can also print the chart by clicking the version's Actions menu in the Statistics Column and selecting 'Print Chart' from its dropdown. Please refer to the Chart Board - Statistics Column section for details.
  5. The hour burndown chart provides you with the following information:
    • Remaining Values - Completed (solid line) — The number of hours remaining until the version release date. For details on how these values are calculated, please refer to How Hour Burndown Charts Relate to Time Tracking in JIRA.
    • Remaining Values - Ongoing (dotted line) — The number of remaining hours burned since midnight on the current day. The gradient of this curve may change throughout this day.
    • Remaining Values - Trend (dashed line) — The projection of remaining hours to be burned until the version release date, based on the actual hourly burn data from the start of the project.
    • Guideline (solid line) — The ideal burndown. This is computed with the remaining estimates, not the original estimates of the hours remaining at the version's start date. Hence, this calculation makes the guideline slope more accurate and precise.
    • Team effort - Completed (solid line) — The total time worked by the team. For details on how these values calculated, please refer to How Hour Burndown Charts Relate to Time Tracking in JIRA.
    • Team effort - Ongoing (dotted line) — The total time worked by the team since midnight on the current day. The gradient of this curve may change throughout this day.
    • Estimate accuracy (solid line) — The sum of the Team Effort and the Remaining Values (that is, number of hours remaining). If you have estimated your issues accurately, this line will be flat. If you are underestimating your issues, this line will trend upwards. If you are overestimating your issues, this line will trend downwards.
    • Estimate accuracy - Ongoing (dotted line) — The sum of the Team Effort and the Burndown, since midnight on the current day. The gradient of this curve may change throughout this day, although if you have estimated your issues accurately, this line will follow a flat trend.
    • Required daily burndown rate (solid line) — The daily hour burn rate required to attain your goal. The is the Burndown divided by the number of days remaining until the end date.
    • Required daily burndown rate - Ongoing (dotted line) — The daily hour burn rate required to attain your goal, since midnight on the current day. The gradient of this curve may change throughout this day.

(tick) Tip: If you set up a version to be the parent version of a number of child versions, you will be able to view the burndowns of the parent and child version merged into one. This can be useful for providing a visual overview of a release with multiple iterations.

Screenshot: Hour Burndown Chart

  1. Apr 03, 2011

    Is there any way to improve the visibility of numbers appearing in the graph. In our case the required hour burn down rate or any other numbers are not visible. What is the use of publishing the data in chart area if the information is not readable?

  2. Oct 12, 2011

    Anonymous

    If you enter task estimate hours mid-sprint then the guideline / remaining lines do not start with the total no. of hours.  Scenario : Sprint starts with 5 stories, 4 of which have hour estimates. The last one requires additional info to estimate. A day later after clarification those estimates begin.  however the guideline still only shows starting from the  estimated hours of the first 4 stories.  How can it be reset to start with the total number of hours now estimated for all the stories?

    1. Oct 27, 2011

      Anonymous

      Yes this has been a long running problem. Adding in estimates later seems to just bump up the Estimate Accuracy line.

    2. Jan 31, 2012

      Anonymous

      Has this problem fixed by now by GreenHopper development team?

       

      1. Jan 31, 2012

        Anonymous

        I am having the same issue I would love to know if there is a solution to this. My burndowns look terrible.

         

        isabella.lascelles@fostermoore.com

  3. Feb 01, 2012

    Anonymous

    The point of sprints is to do estimates before they start rather than in the middle.  That's why sprints are so short.

  4. Feb 01, 2012

    Anonymous

    All estimates are SWAGs no matter what, anyways.  Your best bet is to make sure next sprint is for the product owner / scrum master to make sure they have all the information needed to go into sprint planning so this sort of thing doesn't happen.

  5. Feb 02, 2012

    Could this example graph be updated to be a little more accurate to represent a real-world example?  For example, the yellow line SHOULD stay flat if your estimates are accurate but this graph it follows the green line pretty closely, which is NOT expected.  Also, the blue line should steadily go up as the sprint progresses and people add time (nearly being inverse to the green line, minus any deviation of the yellow line).  It looks like very little time was actually logged in this example, and instead issues were just closed and their remaining estimates zeroed.  Not saying its a bad graph, its just that when I was trying to learn how these worked, and compared it to how ours actually look, it was quite different.