Sprint Burndown

Monitor your team's sprint progress in real time with visual burndown charts that show completed work, remaining effort, and deadline prediction.

What this report shows

Sprint Burndown provides a visual representation of your team's progress through a sprint, showing how much work has been completed and how much remains. The chart helps teams stay on track to meet sprint commitments by providing early indicators when progress falls behind the ideal pace.

Sprint Burndown charts start with your total sprint commitment (measured in story points or issue count) and track daily progress as work gets completed. The chart displays 2 key lines: an ideal burndown line showing the steady pace needed to complete all work on time, and an actual progress line showing your team's real completion rate.

Accessing the report

Navigate to Reports in the left sidebar and select Sprint Burndown. Available filters include a sprint selector, repository filter, labels filter, a toggle to show or hide pull requests, and a burn pipelines selector to customize which pipeline stages count as completed work.

Reading the visualization

The vertical (Y) axis shows total story points remaining. The horizontal (X) axis shows time progression through the sprint. A vertical dashed line marks today's position. Weekends appear with different formatting to account for non-working days.

Ideal line (grey, dashed) shows the steady pace needed to complete all committed work by the sprint end date.

Remaining line (blue, solid) tracks actual remaining work as issues get completed.

Below the chart, 2 summary cards show completion progress: one for story points and one for issues and pull requests, each showing completed, remaining, and total counts with completion percentage.

Understanding the metrics

Story points metrics track total points committed at sprint start, points completed to date, points remaining, and completion percentage. These reflect the complexity-weighted view of sprint progress.

Issue count metrics show total issues assigned, issues completed, issues remaining, and completion percentage by count. These show discrete task completion independent of complexity.

Burn rate is the rate at which work is being completed, calculated from the slope of your actual burndown line. Consistent burn rate indicates predictable team velocity.

Interpreting Sprint Burndown patterns

When your remaining work line closely follows or stays below the ideal line, your sprint is progressing well. Consistent tracking suggests accurate initial scope and timeline estimates.

When the remaining work line tracks significantly above the ideal line, your sprint faces completion risks. This indicates overcommitment, unexpected complexity, or capacity constraints. The earlier you identify this pattern, the more options you have for mitigation.

Upward movement in the remaining work line indicates scope additions during the sprint. Look for slope changes too — steepening indicates accelerating progress, while flattening suggests slowing velocity that may require intervention.

Using Sprint Burndown for planning

Review completed sprint burndowns to understand your team's typical completion patterns. Look for consistent late-sprint crunches, scope creep patterns, or estimation accuracy trends, and use these to calibrate future sprint commitments. When burndown patterns indicate problems early in a sprint, use the data to drive scope discussions with stakeholders before sprint failure becomes inevitable.

Customizing the report

By default, Sprint Burndown considers issues completed when they reach the Closed status. Customize this by clicking Burn pipelines and selecting which pipeline stages count as complete. Multiple pipelines can be configured as done states, allowing teams with complex workflows to track completion accurately.

Use the repository filter to analyze progress for specific projects, and label filters to understand progress for different work categories like bugs vs. features. Export to CSV for detailed analysis or integration with other planning tools.

Troubleshooting common issues

If your burndown chart is empty, verify that your sprint has configured start and end dates and contains estimated issues. Issues without story point estimates won't appear in burndown calculations unless your workspace has Estimated Effort configured in Workspace Settings to provide default values.

For inaccurate completion tracking, ensure the burn pipelines configuration matches your actual workflow and that team members know which actions trigger burndown progress. If issues aren't appearing in sprint reports, confirm they're properly assigned to the sprint.

FAQ

Q: Why doesn't my burndown chart show all the work in my sprint?
A: Only issues with story point estimates appear by default. Ensure sprint work has estimates assigned, or configure Estimated Effort in Workspace Settings to automatically assign default values.

Q: Can I change what counts as completed work in the burndown?
A: Yes. Use the Burn pipelines dropdown to customize which pipeline stages trigger completion in your burndown tracking.

Q: How far back can I view historical burndown charts?
A: Sprint Burndown reports are available for the last 10 closed sprints. Use CSV export to save data from older sprints for long-term analysis.

Q: What happens if I add work to a sprint after it starts?
A: Added work increases the total story points on the chart, potentially causing the burndown line to move upward. This helps track scope changes and their impact on delivery.

Q: Can I track multiple repositories in a single burndown chart?
A: Yes. Sprint Burndown automatically includes issues from all repositories within your workspace sprint, providing unified progress tracking across your codebase.