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

As your team closes issues during the sprint, the chart automatically updates with new data points that "step down" toward zero remaining work. This visual feedback helps identify whether your sprint is on track, ahead of schedule, or falling behind before the sprint deadline arrives.

Accessing the Report

Navigate to the Reports section in the left sidebar and select "Sprint Burndown" to view your burndown charts. The interface provides several filtering and viewing options to customize your burndown analysis.

Available filters and controls:

• Sprint selector: Choose which sprint to analyze from the dropdown showing sprint dates

• Repository filter: Focus on specific repositories when working with multi-repo sprints

• Labels filter: Filter sprint work by GitHub labels to analyze specific types of work

• Show pull requests toggle: Include or exclude pull requests from burndown tracking

• Burn pipelines: Customize which pipeline stages count as "completed" work

Each sprint provides its own dedicated burndown report, allowing you to track current sprint progress and review historical sprint performance.

Reading the Visualization

The Sprint Burndown chart contains several key elements that help you understand sprint progress and make informed decisions about scope and pacing.

Chart axes and scale:

• Vertical (Y) axis: Shows total story points remaining in the sprint

• Horizontal (X) axis: Displays time progression through the sprint duration

Visual indicators:

• Today marker: A vertical dashed line shows your current position within the sprint timeline

• Weekend formatting: Weekend days appear with different formatting to account for non-working days

• Dual progress tracking: Separate completion percentages for story points and issues/pull requests

Progress lines:

• Ideal line (gray, 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

Progress summary cards: Below the chart, two summary cards show completion progress. The Story Points card displays completed, remaining, and total story points with completion percentage. The Issues and Pull Requests card shows the same metrics but counted by individual work items.

This dual tracking helps teams understand both effort-based progress (story points) and velocity-based progress (individual items completed).

Understanding the Metrics

Sprint Burndown tracks multiple related metrics that provide comprehensive insight into sprint progress and team performance.

Story points metrics: Total story points committed at sprint start, story points completed to date, story points remaining, and completion percentage based on story points. These metrics reflect the complexity-weighted view of sprint progress.

Issue count metrics: Total issues assigned to sprint, issues completed (closed), issues remaining open, and completion percentage based on issue count. These metrics show discrete task completion independent of complexity.

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

Ideal pace vs. actual: The gap between your ideal burndown line and actual remaining work line indicates whether you're ahead of, on pace with, or behind your sprint commitments. This comparison provides early warning of potential delivery issues.

Interpreting Sprint Burndown Patterns

Use the visualization patterns and metrics to assess your team's sprint health and identify potential issues before they impact delivery.

Healthy sprint indicators: 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. Steady daily progress without large gaps indicates good team coordination and minimal blockers.

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

Ahead of schedule opportunities: When your remaining work line tracks well below the ideal line, you're progressing faster than planned. This creates opportunities for additional scope or technical debt reduction, though be cautious about scope creep affecting quality.

Scope change indicators: Upward movement in the remaining work line indicates scope additions during the sprint. While some scope changes are inevitable, frequent or large additions suggest issues with sprint planning or stakeholder management.

Progress velocity changes: Look for slope changes in your remaining work line. Steepening slopes indicate accelerating progress, while flattening slopes suggest slowing velocity requiring intervention.

Using Sprint Burndown for Sprint Planning

Transform Sprint Burndown insights into actionable sprint planning improvements and capacity decisions.

Historical pattern analysis: 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. Use these patterns to calibrate future sprint commitments.

Capacity determination: Use your historical burn rate to set realistic sprint commitments. If your team consistently completes 20-25 story points, plan around that capacity rather than aspirational targets. Build in buffer for unexpected issues.

Risk identification: During sprint planning, consider whether new sprint scope matches the profile of successfully completed past sprints. Large scope or significantly different work types increase sprint risk.

Mid-sprint adjustments: When burndown patterns indicate problems early in the sprint, use the data to drive scope discussions with stakeholders. Objective data makes it easier to negotiate scope reductions or deadline extensions before sprint failure becomes inevitable.

Customizing the Report

Configure Sprint Burndown settings to match your team's workflow and completion criteria.

Burn pipelines configuration: 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. For example, if your team considers work done when it reaches "Ready for QA," set that pipeline as your completion trigger.

Multiple pipelines can be configured as "done" states, allowing teams with complex workflows to track completion accurately across different types of work or team responsibilities.

Repository filtering: When your sprint includes issues from multiple repositories, use the repository filter to analyze progress for specific projects or codebases. This helps identify whether delays are localized to particular areas.

Label-based analysis: Filter by labels to understand progress for different work categories (bugs vs features, frontend vs backend). This granular view helps identify whether specific types of work are causing velocity issues.

Export capabilities: Export burndown data to CSV format for detailed analysis, custom reporting, or integration with other planning tools. The export includes daily data points showing date progression, total story points remaining, completed story points, ideal progress pace, and issues completed each day.

Troubleshooting Common Issues

Address frequent Sprint Burndown problems that prevent accurate progress tracking.

Empty burndown charts: Verify that your sprint has properly 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.

Missing issues from burndown: Check that your team is consistently closing issues rather than leaving them open indefinitely. Burndown tracking depends on actual issue closure to register progress, so teams should develop habits around timely issue management.

Inaccurate completion tracking: For teams using custom pipeline definitions of "done," ensure the burn pipelines configuration matches your actual workflow practices. Verify that team members understand which actions trigger burndown progress.

Sprint configuration problems: If issues aren't appearing in sprint reports, confirm they're properly assigned to the sprint. Use the Work Tracker's multi-action feature to bulk-assign issues to sprints when needed.

FAQ

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

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. This allows you to match the report to your team's definition of done.

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 will increase the total story points on the chart, potentially causing the burndown line to move upward. This helps track scope changes during sprints 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.

Q: How do incomplete issues affect my burndown chart?
A: Issues closed outside the sprint timeframe appear in the "incomplete" section but don't affect the main burndown visualization, helping distinguish planned vs. unplanned completions.