Learn how to set up Jira Software Cloud and integrate it with other products and applications.
Learn how to configure your Jira Software Cloud company-managed projects to suit your agile development processes.
Learn how to create, search, and work with issues in software projects, manage your profile, and more.
Learn how to get started, enable features, and manage and administer team-managed projects.
Plan and view work across multiple teams, projects, and releases with Advanced Roadmaps.
A guide on how to deploy and monitor an application built on AWS using Atlassian and third-party tools.
This page is for team-managed projects
If the lower-left of your project sidebar says you're in a company-managed project, check out these company-managed project articles instead.
Learn more about the difference between company-managed and team-managed projects.
Before you begin
What is the Sprint burndown chart?
A sprint burndown chart shows the amount of work that has been completed in a sprint and the total work remaining. Sprint burndown charts are used to predict your team's likelihood of completing their work in the time available. By tracking the remaining work throughout the sprint, a team can manage its progress, and respond to trends accordingly. For example, if the burndown chart shows that the team may not reach the sprint goal, then the team can take the necessary actions to stay on track.
They're also great for keeping the team aware of any scope creep that occurs.
How to read the report
The vertical axis represents amount of work; either number of issues or story points (if Estimation is enabled). The horizontal axis represents the timeframe of the sprint.
The grey line shows the ideal progress rate. It trends downwards at a linear rate, because teams should ideally be completing work at a consistent pace.
The red line shows how much work remains in the sprint. The closer this line is to the grey line, the better.
The report also has a number of tables that provide more context for the chart. Table data can be sorted by selecting the column header. The tables are:
Scope changes log: Issues that were added to the sprint, removed from the sprint, or had estimation changes, while the sprint was in progress.
Incomplete issues: Issues in the sprint that were never completed (ie: never moved to a Done status). This includes issues that were never started.
Completed issues: Issues that were moved to a Done status while the sprint was in progress.
Issues completed outside of sprint: This includes issues that were:
completed and then added to the sprint, either before the sprint started or after the sprint started.
added to the sprint, but completed before the sprint started.
Issues removed from sprint: Issues that were removed from the sprint while the sprint was in progress.
Things to keep in mind
If the Estimation feature has been enabled, your report will display using your team's story point estimates for each issue.
If Estimation hasn't been enabled, your report will display using the number of issues, which means they will treat each issue as having equal weighting.
The report does not use data from subtasks, even if your project's subtasks have their own estimates. The report will only use data from standard-level issue types like Stories, Bugs, or Tasks.
Was this helpful?