BD - Configuring Burndown report
At first, make sure you add this report to your dashboard. To see more instructions about adding a gadget to your dashboard see Atlassian documentation.
Configuring Burndown report
To configure the Burndown report, click Edit and fill out the necessary fields (described below).
Fields description
| Field | Description |
|---|---|
| Display data for | You can build your report on a Jira project, SCRUM board, or a saved filter. Project If you select a Jira project, the report will show how the work is being delivered inside a particular project and will calculate work on the tickets belonging to the selected project only.
SCRUM board If you select a SCRUM board, the report will show how work is being delivered by a particular SCRUM team.
Saved filter This is the most flexible way to display data for the Burnup / Burndown report. You can create any filter in Jira to display the tickets that you need, save it, and select for the report. You can use it for Program level reporting if your company uses SAFe.
|
| Filter by | This is the additional filter that you can select for a quick tailored view. If you selected a Project, you can additionally filter the report by Release (Jira version) and global single select custom fields. Note that in this case you cannot filter by Sprints because a Sprint is a notion of a board and is not present for a project report. To filter data by Sprints, select a SCRUM board or a saved filter.
If you selected a SCRUM board, you can additionally filter the report data by Sprint and global single select custom fields. Note that in this case you cannot filter by Jira versions because a Release (Jira version) is a notion of a board and is not present for a SCRUM board report. If you want to display data for a particular Release, select a project.
If you selected a saved filter, you can filter by global single select custom fields but you cannot filter additionally by version or a sprint. The Release (version) is the notion of a project and a saved filter can have multiple sprints for the same time period so there would be no way for the report to know which sprint to pick. However, you can work around this on the stage of creating a saved filer and filter out any tickets that you need.
|
| Start reporting at | Start date for the report. If you select a start date that is in the middle of the sprint, the report autocorrects this date in order for you to have the most accurate data grouped by whole sprints. |
| End reporting at | The end date of the report. If the field is not filled in, the end date is set to the current date. Note that if you select the end date that is in the middle of the sprint, the report autocorrects this date in order for you to have the most accurate data grouped by whole sprints. In order to have a meaningful report, report dates should adhere to certain rules - both dates should be in the past (the end date can be current day) and have at least 5 days between them. |
| Report cumulates | Time metrics for your report, measured in man-days (MD) or story points (SP). |
| Report type | For some teams this is convenient to view their progress from the "how much have we accomplished" perspective while others are more interested in "how more is there left to do" metrics. You can flip the chart lines so that the report is either a burnup or a burndown of your team's progress. |
| Show deviation lines | Opt to work with the deviation lines or not. |
| Limit lines at | User defined acceptable deviation from the plan, measured in % and can be between 10% and 90%. Deviation is a difference between the planned work (estimates in SP or MD) and actual delivered work (actuals in SP or MD) for a selected time frame. You can define what you consider to be a norm as a deviation % from estimates. For example, if you set the deviation to 20%, you allow your team to be 20% behind the schedule. This gives certain relief to the teams, as it is difficult to provide accurate estimates but as long as they are within the deviation norm, the team progress is on track, and you do not get warnings every time when the actuals line is below the estimates. After you set the deviation percentage, the deviation lines appear on the chart and show the area around the estimates where the delayed actual progress is still considered as on track. Everything below the Deviation (late) line is considered to be in danger zone as this means that the work is behind the plan for more than an established deviation norm. The danger zone is marked as a transparent red area below the Deviation (late) line. Thus, the main thing is not to let the actuals line get into the danger zone. |
| Refresh Interval | The interval at which you want the gadget to be updated. |
Tips for using the Burnup / Burndown report
For you to have a meaningful data on the Burndown report, check on the following items:
- You have at least 1 active sprint on the SCRUM board to be able to filter by SCRUM board
- There are at least 5 days between the start and end dates for the report
- Deviation percentage is not greater than 30%. If it's very low (10% for instance), then your team has to operate in very tight boundaries and will often fail to be on track even though their progress might be good enough. If you set the deviation for more than 30%, reporting starts to lose its purpose as a very significant delay will not ring the bell, you will not get the warnings, while the work delay might be an alarming one.
- You check the Warnings tab from time to time and process tickets there. The tickets shown in the Warnings tab are not included into the chart calculations, and to see the accurate picture on the chart, you might want to triage those tickets first.