Burndown and burnup guidance
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Burndown and burnup charts support project management to visually track work completed over time. The main differences between the two chart types are:
- Burndown charts begin with the total amount of planned work and then as work is completed graphs the remaining work. With the progression of time, the amount of to-do work decreases.
- Burnup charts track work as it is completed over time. They are useful to show the rate at which work is getting completed.
- Sprint burndown charts track planned work for a team and a selected sprint. Sprint charts can help teams review how efficient they are in planning and executing sprint over sprint.
In general, burndown charts should show a downward trend. However, if teams add work through a sprint or release period, then the chart will show upward trends. These charts help teams monitor what they planned to do versus what they actually do.
Burnup charts, on the other hand, should always show an upward trend as work is completed over time. The following configurable charts and widgets are available for tracking burndown or burnup.
- Burndown/burnup widget (Analytics)
- Sprint burndown built-in report (Analytics)
- Sprint burndown widget (Analytics)
- Sprint burndown widget (Legacy) (Work item store)
Review your sprint burndown chart throughout your sprint cycle to check for these indicators:
- Is remaining work getting updated regularly? Flat spaces within the blue area indicate a lack of updates.
- Is remaining work increasing instead of decreasing? Increases can indicate work that wasn't estimated or planned. Both signal a need for the team to discuss how they'll complete the sprint tasks on time.
- Based on the actual burn rate, does the team feel confident that they'll complete the work by the end of the sprint?
You can view sprint burndown from your team's sprint backlog built-in report or by adding the Sprint burndown widget to a team dashboard.
To configure or view sprint burndown charts, see Sprint burndown.
Important
Deleting Area Paths or reconfiguring Iteration Paths can cause a loss of data and can't be reverted. For example, burndown or burnup widget charts, sprint burndown, and velocity charts for teams whose Area Paths are changed won't reflect correct data. Historical trend charts reference the Area Path and Iteration Path as defined at a point in the past for each work item. When an Area Path or Iteration Path is deleted, then the historical data for it can't be retrieved.
Supported configuration options
The following table summarizes the configuration options supported by the various burndown chart options. Sprint burndown charts are always focused on a single team, whereas a Burndown/Burnup widget can track work for several teams. All charts support tracking by work item count or a sum of Story Points, Effort, Remaining Work or other custom (integer or decimal) field.
| Configuration | Sprint burndown report | Sprint burndown widget | Burndown/Burnup widget |
|---|---|---|---|
| Team(s) | Single team | Single team | One or more teams |
| Backlog | Product backlog, Task backlog |
Product backlog, Portfolio backlog, Any work item type |
Product backlog Portfolio backlog work item type |
| Work item field filters | None | None | Supported |
| Burndown focus | Count or Sum | Count or Sum | Count or Sum |
| Time period | Single sprint | Single sprint | Configurable |
For details on viewing and configuring charts, see Configure and monitor sprint burndown or Configure a Burndown or Burnup widget.
General guidance
Depending on the teams, work item types, and time period you want to monitor, choose the chart option according to the following guidance.
| Monitor | Chart option |
|---|---|
| Sprint burndown for a team | Sprint burndown chart |
| Sprint burndown for a specific work item type or a portfolio backlog | Sprint burndown widget |
| Sprint burndown for several teams | Burndown widget |
| Release burndown/burnup for one or more teams or teams in different projects | Burndown/Burnup widget |
| Burnup or burndown for any type of work item and time period | Burndown/Burnup widget |
| Project and target completion date | Burndown/Burnup widget |
Scope management
By estimating remaining work of tasks for each backlog item, teams better understand what they can accomplish within a sprint. Because the sprint tasks define the overall sprint scope, defining the remaining work leads to a well-defined sprint scope. Anything that isn't represented by a task in the sprint should be considered out of scope for the sprint.
As the team makes progress, divergences from the ideal trend line help the team monitor divergences from scope.
Note
The Show non-working days shades those days set through the team's Working days setting as well as the team's days off set through the Capacity page.
Increases instead of decreases within the blue graph may indicate:
- Poor estimates made to tasks
- Discovery of new work not accounted for in sprint planning
- Scope creep, other work not agreed to by the team.
Whatever the cause, teams should come together quickly to determine how to remedy the increased workload.
Solutions may include reassigning tasks or recruiting more resources. The team should move all non-essential sprint work to the backlog and consider it during the next sprint planning meeting.
As the team makes progress, divergences from the ideal trend line help the team monitor divergences from scope.
Increases instead of decreases within the blue graph may indicate:
- Poor estimates made to tasks
- Discovery of new work not accounted for in sprint planning
- Scope creep, other work not agreed to by the team.
Whatever the cause, teams should come together quickly to determine how to remedy the increased workload.
Solutions may include reassigning tasks or recruiting more resources. The team should move all non-essential sprint work to the backlog and consider it during the next sprint planning meeting.
Mitigate risk through daily inspection
Your burn-down chart shows you if your project is on schedule. A daily check can mitigate risks and provide early warning of potential schedule or cost overruns, two metrics associated with traditional project management.
For example, when the actual remaining work (blue area) goes flat for a while, or remains high above the ideal trend line, the team is at risk of not meeting their sprint commitments.
Teams should meet immediately to course correct and either reassign work, recruit more resources, or reset expectations.
Your burn-down chart shows you if your project is on schedule. A daily check can mitigate risks and provide early warning of potential schedule or cost overruns, two metrics associated with traditional project management.
For example, when the actual remaining work (blue area) goes flat over time, or remains high above the ideal trend line, the team is at risk of not meeting their sprint commitments.
Teams should meet immediately to course correct and either reassign work, recruit more resources, or reset expectations.
Next steps
Related articles
- Velocity metrics and usage guidance
- Implement Scrum practices for your team in Azure Boards
- Query by date or current iteration, List work items moved out of a sprint
- Query by date or current iteration, List work items added to a sprint after the start date
- Manage priorities and gain visibility across teams
Industry resources
Feedback
Submit and view feedback for