Viewing the Epic Burndown

The current sprint is usually not counted when calculating the team's velocity. In the example above, the current sprint bar shows grey sections (like the bars for the predicted sprints) to represent this. The exception is when you have already completed more work in the current sprint than the work that was predicted to be completed. In this case, the current sprint (and the actual work completed) is used as one of the three sprints used to calculate the velocity. Also, the sprint bar will show green/blue sections, like the bars for completed sprints.

For example, in the chart above, if your team had not completed more than 2 story points in sprint 10, then the work completed in sprint 7, sprint 8 and sprint 9 would be used to calculate the velocity, rather than sprint 8, sprint 9 and sprint 10.

• The first sprint shown is the one that contains the first issue (in the epic) that transitions out of the To Do status, i.e. work is started on the epic.
• The last sprint shown is the one when all work is completed for the epic; or if work remains, then the predicted sprint when work will be finished.

The mapping of statuses to your board determines when an issue is considered "To Do" or "Done". See Configuring Columns for more information.

The Epic Burndown report can only make predictions based on the estimated issues in your epic. This does not include issues that cannot be estimated (e.g. you have configured an issue type to not have the Story Points field). If you have a high percentage of unestimated issues, then the predictions in the report will not be reliable (the % unestimated issues label is coloured red when the percentage is above 30%, to help make you aware of this).

For example, if you have only estimated 10% of the issues in the epic, then the report predicts the completion of work for the epic based on the 10% of the total issues. In reality, your team probably has much more work left to complete.

The following changes affect the original estimate of a sprint:

• An issue in an epic (before it started) is estimated (estimate is added)
• An issue in an epic (before it started) is re-estimated (estimate changes)

The following changes affect the scope of a sprint:

• An issue is added to an epic (after it was started) with an existing estimate
• An issue that was added to an epic (after was it started) is estimated (estimate is added)
• An issue that was added to an epic (after was it started) is re-estimated (estimate changes). Note, if the issue is re-estimated in a later sprint, the scope is retroactively adjusted in the sprint that the issue was originally added to.

Any change (burndown or scope) that occurs outside a sprint will be shown as part of the sprint with the latest start date before the change date.

Issue completed in a sprint, then re-opened:

• The issue will not be shown in the earlier sprint.

Issue completed in an epic, but removed from the epic afterwards:

• The scope will remain unchanged and the work completed is still shown.

Issue completed in another epic, but later included in the epic (shown on the report):

• The scope will remain unchanged.

Issue completed in a sprint, but only added to the epic afterwards:

• The issue will be shown on the report, as if it was always part of the epic.

If your issue is in an unmapped status (i.e. status not mapped to a column), it will not be considered in the Epic Burndown chart. That is, it won't be included in the sprint bars, the % unestimated issues, remaining story points, etc.

In the 'Completed Issues' table, an issue is grouped into a sprint if its completion date falls after the start date of the sprint and before the start date of the next sprint, regardless of whether it was assigned to the sprint during planning.

For example, consider the following sample data:

• Sprint 1 — starts on July 1 and ends on July 14
• Sprint 2 — starts on July 17 and ends on July 30

Say issue 'ABC-123' was assigned to Sprint 1 during planning, but was not completed until July 18. In the 'Completed Issues' table, ABC-123 would be grouped under Sprint 2, rather than Sprint 1. This is a more accurate reflection of what happened during the epic and helps maintain the integrity of the report data.