
Note that this page only applies if you are using the
Classic Boards (which are no longer being actively developed;
read more).
If you are using the new boards, please see
Viewing the Burndown Chart.
To view the hour burndown chart for your project version,
- Log into JIRA.
Select Agile > Classic in the top navigation bar. Then select Classic Chart Board from the drop-down below the project name.
- 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.
- 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 enabled for GreenHopper).
- 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 (see Managing Versions); 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.
- 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.
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

15 Comments
Yogesh Varma
Apr 03, 2011Is 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?
Anonymous
Oct 12, 2011If 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?
Anonymous
Oct 27, 2011Yes this has been a long running problem. Adding in estimates later seems to just bump up the Estimate Accuracy line.
Anonymous
Jan 31, 2012Has this problem fixed by now by GreenHopper development team?
Anonymous
Jan 31, 2012I 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
Anonymous
Feb 01, 2012The point of sprints is to do estimates before they start rather than in the middle. That's why sprints are so short.
Anonymous
Feb 01, 2012All 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.
Anonymous
Jul 25, 2012What if I need to see a project hour burndown chart, in this case I don't know estimates for some issues.
Dave Hergert
Feb 02, 2012Could 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.
Anonymous
Mar 13, 2012Noticed the same thing. Good remarks.
Anonymous
Apr 11, 2012How can I edit an existing version's start date that was not originally created using the planning board?
Anonymous
Jun 05, 2012With the correct permissions, you will have a small "edit pencil" when you hoover the "start date" line in the statistics box at the right.
Steve Lane
Jun 16, 2012I can speak to the question some posters had about why the original estimate for a sprint doesn't change to include tasks added during the sprint. GreenHopper is essentially enforcing a specific interpretation of sprints and estimates. The "original estimate" for a sprint is by definition the "original" estimate, i.e. the estimate at the start of the sprint. Tasks added after the sprint began are by definition not part of the ORIGINAL estimate.
See the discussion here.
In Atlassian's view this is not a bug or a problem, it's a feature/intended behavior. Not saying I agree, but there it is.
Anonymous
Jul 05, 2012When I view the Chart board of a single assignee it's showing me a chart of all estimates and time spent for all the issues currently assigned to that assignee regardless of who logged the time. Is there a way to show chart board information for an individual based on the individual work logs? I don't want to assume everything assigned to a user was logged by that user?
Anonymous
Nov 08, 2012Is there any way to show the username below the burndown chart? We want to have visibility into the time logged and remaining for each member of the team.