TFS 2017 | TFS 2015 | TFS 2013
Excel reports, Reporting Services reports, and SharePoint dashboards are only supported for on-premises TFS. For information on what is supported for Team Services, see Dashboards and reports overview.
By reviewing the release burndown report, you can understand how quickly your team has delivered backlog items and track how much work the team must still perform to complete a product release.
This report requires that the team project collection that contains your team project was provisioned with SQL Server Reporting Services. This report is not available if Reports does not appear when you open Team Explorer and expand your team project node.
To view the report, you must be assigned or belong to a group that has been assigned the Browser role in Reporting Services. For more information, see Grant permissions to view or create reports in TFS.
Data in the report
As the following illustration shows, a release burndown graph shows how much work remained at the start of each sprint in a release. The source of the raw data is your product backlog. Each sprint that has been assigned to the team project or team appears along the horizontal axis. The vertical axis indicates the sum of all effort of all active backlog items at the start of each sprint. As the team updates the state of backlog items to Done, the effort remaining decreases. The amount of estimated effort on the vertical axis is in whatever unit that your scrum team has decided to use (for example, story points, size, or hours).
You can filter the report by selecting the Release Path or Area.
Required activities for tracking release burndown
For the burndown graph to be useful and accurate, your team must perform the following activities for tracking work items:
Specify the number of releases you want to track and define the start and end dates for each sprint.
Define product backlog items and bugs, and assign each to a sprint or iteration. (Iteration field). Make sure that all backlog items are assigned to your team's area path or subarea.
At the start of a release, estimate the Effort for each product backlog item and each bug that your team will work on.
During the sprint or at the close of each sprint, for each product backlog item and each bug that the team completed, change the State to Done.
Interpreting the report
You can review the report to determine the progress that your team has made in a release and to answer the following questions:
How much work remains in the release?
How quickly is your team working through the product backlog?