How to Create a Sprint Burndown Chart in Jira
A sprint burndown chart is the simplest way to answer the question every PM dreads mid-sprint: are we going to finish everything we committed to? Without this visibility, teams discover on the last day that they are behind, leaving no time to adjust scope or communicate delays to stakeholders.
Jira generates burndown charts automatically for active sprints, but most teams glance at them without understanding what the chart shape reveals about their process. This guide covers setting up your Jira board for accurate burndowns, reading the chart to diagnose common problems, and using the data to improve sprint planning over time.
Step-by-step guide
Configure your Jira board for burndown tracking
Navigate to your Jira board settings and ensure you are using a Scrum board (not Kanban). Verify that estimation is enabled under Board Settings > Estimation. Choose your estimation statistic — story points are the most common, but you can also burn down by issue count or time tracking. Whichever you choose, ensure every issue in the sprint has an estimate; issues without estimates are invisible to the burndown chart.
- Go to Board Settings > Estimation and select Story Points as the estimation statistic
- Verify that the 'Story Points' field is visible on your issue creation screen
- Check that all issues in your current sprint have point estimates assigned
Plan and start a sprint with estimated issues
In your backlog, drag estimated issues into the sprint and verify the total points align with your team's historical velocity. When you start the sprint, set the correct start and end dates — these define the ideal burndown guideline on the chart. The ideal line assumes linear progress, so if your two-week sprint has 40 points, the guideline shows 4 points completed per day.
- Review the sprint total against your team's average velocity from the last 3 sprints
- Set the sprint duration accurately — the guideline is only useful if the dates are correct
- Ensure no unestimated issues are included in the sprint before starting it
Access and read the burndown chart
Click on Reports in your Jira project sidebar and select Sprint Burndown. The chart shows remaining work (y-axis) over time (x-axis) with two lines: the gray guideline showing ideal linear progress and the red/blue actual line showing real progress. The gap between these lines tells you whether you are ahead, behind, or on track.
- The ideal line starts at total committed points and ends at zero on the sprint end date
- The actual line updates as issues are moved to Done (or their status changes to a Done category)
- Vertical jumps upward in the actual line indicate scope was added mid-sprint
Diagnose common burndown patterns
A flat line early in the sprint followed by a steep drop at the end means the team batches work and delivers everything in the last days — this is risky because it leaves no buffer for problems. A line that trends above the ideal line means the team is behind and may not complete all commitments. Upward spikes indicate scope creep — issues were added to the sprint after it started.
- Flat then steep: break large stories into smaller ones that can be completed daily
- Consistently above ideal: reduce sprint commitments or identify what causes mid-sprint blockers
- Upward spikes: establish a sprint scope freeze policy and track added scope as a separate metric
Use burndown data to improve sprint planning
After each sprint, compare the final burndown shape to your initial plan. Calculate your completion rate (completed points / committed points) and track it over sprints. If your team consistently completes 70% of committed points, your velocity estimate is too optimistic. Use the rolling 3-sprint average completion rate to calibrate future sprint commitments.
- Record the committed and completed points for every sprint in a simple tracking spreadsheet
- Calculate rolling 3-sprint velocity average and use it to plan the next sprint
- Flag sprints where scope was added mid-sprint separately to avoid distorting your velocity baseline
Common mistakes
Not estimating all issues before starting the sprint
Unestimated issues do not appear on the burndown chart, making the remaining work look smaller than it actually is. This creates false confidence mid-sprint and a surprise overrun at the end. Require estimates on every issue before sprint start.
Adding scope mid-sprint without adjusting commitments
Every issue added mid-sprint increases the total work but the sprint end date stays fixed. If you must add scope, remove an equivalent amount of planned work. Track mid-sprint additions separately so you can address the root cause in retrospectives.
Using the burndown chart as a performance metric
Burndown charts measure sprint progress, not team performance. Using them to pressure the team leads to gaming — splitting large stories into tiny pieces to show artificial progress, or under-estimating to guarantee completion. Use burndowns for planning calibration, not accountability.
Tips
Break stories into tasks that can be completed in one day or less — this creates a smoother burndown curve and makes blockers visible faster
Check the burndown chart during daily standup so the team sees their trajectory and can adjust priorities before it is too late
Use Jira's Sprint Report (not just burndown) for a complete post-sprint analysis that includes added scope, removed scope, and incomplete work
Compare burndown charts across sprints to identify patterns — if burndowns always flatten on Wednesdays, investigate what happens mid-week
How Vantage helps
Vantage generates wave-based tickets with effort estimates and dependencies that naturally map to sprint planning. When you push tickets from Vantage to Jira, they arrive pre-estimated and sequenced, giving your burndown chart accurate data from day one instead of requiring a separate estimation ceremony.