Release Burndown

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013
Azure DevOps Server was previously named Visual Studio Team Foundation Server.

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 Report Reports does not appear when you open Team Explorer and expand your team project node.

Required permissions

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).

Release burndown chart

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?

Scrum process
Define area paths or Define iteration paths