How do I track sprint progress with Sprint Burndown?

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.

Understanding Sprint Burndown charts

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 Sprint Burndown reports

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:

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

Setting up sprints for burndown tracking

Sprint Burndown requires properly configured sprints with defined start and end dates. Create sprints using Zenhub's sprint management features, which allow you to set up automatic sprint schedules that create and close sprints according to your team's cadence.

Add estimated issues to your sprints to populate the burndown chart with meaningful data. By default, issues without story point estimates won't contribute to the burndown visualization. However, if your workspace has "Estimated Effort" configured in Workspace Settings, unestimated issues will automatically receive default values and appear in burndown tracking.

Adding issues to sprints efficiently

Use the Work Tracker's multi-action feature to add multiple issues to a sprint simultaneously. Select issues using the multi-action mode, then assign them to the current sprint in bulk. This workflow is particularly useful during sprint planning when organizing numerous backlog items.

You can also add story point estimates to multiple issues at once using the same multi-action approach, ensuring all sprint work contributes to accurate burndown tracking.

Interpreting burndown chart elements

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 or issue count remaining in the sprint
• Horizontal (X) axis - Displays time progression through the sprint duration with weekends clearly marked

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:

• Story Points card - Displays completed, remaining, and total story points with completion percentage
• 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).

Customizing completion definitions

By default, Sprint Burndown considers issues "completed" when they reach the Closed status. However, you can customize this definition using the "Burn pipelines" dropdown to match your team's workflow and definition of done.

For example, if your team considers work complete when it reaches "Ready for QA" rather than fully closed, set that pipeline as your completion trigger. This customization provides more accurate burndown tracking aligned with your specific development process.

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.

Reviewing sprint details and work breakdown

Below the burndown chart, you'll find detailed listings of all sprint work with rich context about each item's status and characteristics.

Work item details

Each issue and pull request shows:

• Current pipeline - Which workflow stage the item currently occupies (Backlog, Ready for Dev, etc.)
• Labels - Color-coded GitHub labels indicating work type, priority, or other categorization
• Time tracking - When items were added to the sprint (e.g., "added 11 days ago")
• Estimation status - Whether items have story point estimates or show "Not estimated"

Current sprint sections

For active sprints, work is organized into:

• Remaining issues and PRs - Open work that still needs completion, with full pipeline and label context
• Completed issues and PRs - Work finished within the sprint timeframe

Completed sprint sections

For closed sprints, additional categorization appears:

• Completed issues and PRs - Work finished during the sprint period
• Incomplete issues and PRs - Work that was closed outside the sprint start/end dates

[TIP] Use the detailed item information during retrospectives to understand pipeline bottlenecks, estimation patterns, and scope management for future sprint planning.

Multi-repository sprint tracking

Sprint Burndown supports tracking work across multiple repositories within your workspace. When your sprint contains issues from different repositories, the burndown chart provides a unified view of progress regardless of where individual issues are located.

Use the repository filter options to focus on specific repositories when analyzing progress patterns or identifying bottlenecks in particular parts of your codebase or project structure.

Export and analysis 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 through the sprint
• Total story points remaining
• Completed story points
• Ideal progress pace
• Issues completed each day

This exported data supports deeper analysis of team velocity patterns, estimation accuracy, and sprint planning improvements over time.

Using burndown data for sprint planning

Historical burndown charts provide valuable insights for improving future sprint planning. Review completed sprint burndowns to understand your team's typical completion patterns, identify common obstacles, and calibrate story point estimates.

Pay attention to common patterns like slow starts (steep burndown near sprint end), scope creep (upward movement in remaining work), or consistent early completion that might indicate conservative planning.

Combine burndown insights with velocity data to make more accurate sprint commitments and set realistic expectations with stakeholders about delivery timelines.

Troubleshooting burndown issues

If your burndown chart appears empty or inaccurate, 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 for unestimated work.

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.

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

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.

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.

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.

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.

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.