Task burndowns

About this report

The task burndown report is more than simply a burn down report. It is a highly flexible multi-purpose burn down reporting tool. Once launched, the user may explore burn downs for the entire team, for the Development Tasks, Quality Tasks, or for specific individuals on the team across those 3 areas. The report is useful for any member of an Agile team exploring where opportunities for improvement may lie.

After selecting both a program increment and a sprint, the default burn down (the full sprint) is shown, covering all members of the team. Click the Extra Configs button to access filters that rescope the report to focus on Development Tasks, Quality Tasks, or Other defined tasks; you can also select specific team members to see burn down details based upon specialization.

Four plots are available on the report shown in various colors, including:

• Actual Status - Sum of all task hours and projected hours (for un-estimated tasks) included in the sprint
• Burn Target - This is the ideal trajectory needed to close all tasks hours by the end of the sprint
• Hours Available - The meaning of this metric is defined by:
• Full Burndown: hours available = (sum of all sprint participants) * (all participant sprint allocations) * (total hours in the defined sprint length)
• Development: hours available = (sum of Development participants) * (Development participant sprint allocation) * (total hours in the defined sprint length)
• Quality: hours available = (sum of Quality participants) * (Quality participant sprint allocation) * (total hours in the defined sprint length)
• Other:  hours available = (sum of Other participants) * (Other participant sprint allocation) * (total hours in the defined sprint length)
• Burn Up - Sum of completed task hours 

To navigate to this report:

If you’re using the new navigation:

1. Select Teams in the top navigation bar and select the team you want to view information about.
2. On the sidebar, select Reports in the list of options.
3. Select Task burndown report; the report displays.

If you’re using the old navigation:

1. Select the Reports icon from the left Navigation menu.
2. Start typing the report's name in the Search box.
3. Once found, select the report.
   Note: You can also use the categories on the left to search for the needed reports.

Prerequisites

1. PI must exist in the system, with Sprints defined. 
2. Features must be created and tied to the PI. 
3. Stories, with point values, must be created and tied to features. 
4. Stories must be assigned to sprints. 
5. Tasks must be created and assigned to stories. 
6. Tasks ideally should be estimated in hours. 
7. Teams members must be aligned to target sprints and tasked to stories. 

How are report values calculated? 

1. The horizontal axis displays the range of the sprint, from start date to finish date; this information is defined in the Sprint List/New Sprint panel. 
2. The vertical axis displays the range of effort hours; assigned to tasks via the Sprint List/New Sprint panel. 
3. The starting point of all line segments = Sum of all effort hours for tasks in the sprint at the start date.
4. As Tasks are completed, effort hours are subtracted from the sprint total, causing the graphed lines to trend downward, showing remaining hours for each day of the sprint.
5. The ending point of all line segments = Sum of all effort hours for Tasks in the sprint remaining at the end date.

 How to interpret this report

Assuming the team has estimated tasks accurately and no unforeseen problems have occurred, the Hrs Available should track to the "ideal" Burn Target. Although, some variation around the Burn Target line should be expected. The Actual Hours line should ideally remain constant throughout the sprint, although it is not uncommon for some slight variation there as well, due to discovery occurring throughout the sprint.

Generally, the further the Hrs. Available line rises above the Burn Target, the lower the probability that the team can complete all of the tasks defined for the sprint, without adjusting allocations. Keep in mind that the objective of Agile is to maintain the highest sustainable and consistent velocity that is possible over time. Reallocation on a regular basis is less than ideal and should be frowned upon. 

Use the results of the graphs to make corrections in the upcoming sprint. For example, you may need to leverage the Jira Align planning and estimating tools to improve the quality of your story estimates which will in turn, improve the quality of your tasking.