Sprint HealthDecember 18, 2025· 7 min read

Understanding Sprint Velocity and Burndown Charts in Azure DevOps

Sprint velocity and burndown are the two most fundamental agile metrics. Learn what they measure, why they matter, and how Agile Analytics enhances them beyond the built-in Azure DevOps reports.

#sprint velocity#burndown#scrum#azure devops#sprint metrics

Sprint velocity and burndown charts are the foundation of scrum measurement. Yet many teams look at them in isolation, miss the context they provide together, and draw the wrong conclusions. This guide explains what these metrics actually tell you and how to use them to improve sprint-over-sprint predictability.

What Is Sprint Velocity?

Velocity measures how much work (in story points) your team completes per sprint on average. Agile Analytics visualizes the last 6 completed sprints with committed vs. completed bars side by side, plus a commitment reliability percentage.

Commitment Reliability

Commitment reliability = completed points ÷ committed points × 100. A healthy team typically achieves 85–100%. Consistently below 80% signals over-commitment or external blockers. Consistently above 110% often means under-commitment or "sandbagging".

Velocity Trends

A single sprint's velocity is nearly meaningless. What matters is the trend over 4–6 sprints. Agile Analytics plots a trend line so you can see whether your team's throughput is stable, growing, or declining.

What Is a Burndown Chart?

A sprint burndown shows how much work remains in a sprint over time, compared to an ideal linear burn. Agile Analytics renders a real-time burndown that updates as work items are completed or added.

  • Ideal line — straight diagonal from total committed points to zero on the last sprint day
  • Actual line — plots remaining story points at the end of each working day
  • Scope line — tracks total committed points, highlighting scope changes mid-sprint

Reading the Burndown: Common Patterns

The shape of the burndown tells a story:

  • Flat burndown early, steep drop at end — "big bang" delivery, tasks not broken down small enough
  • Rising scope line — mid-sprint scope creep, stories added after commitment
  • Burndown below ideal line early — work being completed ahead of schedule or points were over-estimated
  • Flat actual line — team is blocked or work items are not being updated daily

Using Velocity and Burndown Together

Velocity tells you how much your team delivers. Burndown tells you how they deliver it throughout the sprint. Together they reveal whether your team has consistent habits or is relying on last-minute heroics. Agile Analytics shows both on the same Sprint Health dashboard so you can correlate patterns across sprints.

Tips for Improving These Metrics

If your velocity is inconsistent or your burndown looks unhealthy, here are actionable improvements to try:

  • Break stories into tasks of 4 hours or less to enable daily progress visibility
  • Define a clear "Definition of Done" to prevent work items from lingering in almost-done states
  • Protect the sprint — establish a policy that no new work is added after Day 2 without removing an equivalent item
  • Update work item states daily as a team habit, not just at standup
  • Review the commitment reliability trend in sprint retrospectives and discuss the root causes of misses

Turn sprint reporting questions into a buying path

Use the sprint reporting landing page if the buyer is comparing options, then install Starter to evaluate the workflow in Azure DevOps.

Related reading