How To Calculate Sprint Velocity In Azure DevOps

Many people think velocity is a performance target. It is not. It is a planning tool. In this article, I am going to walk you through exactly how to calculate, configure, and visualize sprint velocity specifically within Azure DevOps (ADO). I will show you how to set up your environment so the platform does the heavy lifting for you.

How to Calculate Sprint Velocity in Azure DevOps

What is Sprint Velocity in the Context of Azure DevOps?

Before we click any buttons, we need to agree on the math. In Azure DevOps, velocity is not just a vague feeling of “fast.” It is a hard metric calculated at the end of every iteration.

Fundamentally, velocity is the sum of Story Points, Effort, or Size for all work items (User Stories, Product Backlog Items, or Bugs) that were completed within a specific sprint iteration.

The Azure DevOps Calculation Logic

When I look at the Velocity chart in ADO, the system is performing a specific query:

Input: It looks at a specific Team and a specific Backlog Level (usually “Stories” or “Requirements”).
Filter: It identifies work items assigned to past Iteration Paths (Sprints).
Validation: It checks the State of those items. Only items in the “Completed” state category (e.g., Closed, Done) count toward the actual velocity.
Summation: It aggregates the values in the “Story Points” field (or whichever field you use for estimation).

Note: If a User Story is moved to “Done” after the sprint end date, Azure DevOps handles this in a specific way depending on your widget configuration, often marking it as “Completed Late.”

Prerequisites for Accurate Velocity Calculation

Verify these three settings in your Project Configuration.

1. Consistent Iteration Paths

Your sprints must be defined with clear Start and End dates.

Go to Project Settings > Boards > Project Configuration > Iterations.
Ensure your sprints (e.g., Sprint 24, Sprint 25) are set up. If you have overlapping dates or missing dates, the velocity calculation will break because ADO cannot time-box the work items.

2. Assigned Work Item Estimates

You must use a consistent field for estimation. In the US, the standard for Scrum teams is Story Points (Fibonacci sequence: 1, 2, 3, 5, 8…).

If you leave the Story Points field empty, your velocity will be zero, even if you closed 50 tickets.
I recommend enforcing a process where no ticket enters an active sprint without an estimate.

3. State Category Mapping

Azure DevOps uses “State Categories” (Proposed, In Progress, Completed) to track work.

Verify that your workflow states (e.g., Ready for QA, Merged) map correctly to the standard categories. If your “Deployed” state isn’t mapped to “Completed,” those points won’t count toward velocity.

Method 1: The Built-In Analytics Velocity Chart

The quickest way for me to check my team’s performance without configuring a custom dashboard is using the built-in Analytics tab. This is available out-of-the-box for every team in Azure DevOps.

Step-by-Step Access

Navigate to Boards: On the left-hand sidebar, hover over Boards and select Backlogs.
Select Your Team: Ensure you are viewing the correct team context (e.g., Team Alpha) from the dropdown in the top right.
Enable Analytics: Click on the Analytics tab located next to the “Editor” tab at the top of the backlog view.

Interpreting the Default View

Once I load this view, I am presented with a bar chart showing the last several sprints.

The Blue Bar (Planned): This represents the total story points assigned to the sprint on Day 1. It gives me a baseline of what we thought we could do.
The Green Bar (Completed): This is the actual velocity—the points we actually finished.
The Gap: If the Blue bar is significantly higher than the Green bar, I know immediately that we are overcommitting.

This view is excellent for a quick “health check,” but for a more permanent and customizable view, we need to build a Dashboard Widget.

Method 2: Configuring the Velocity Widget on a Dashboard

This is where I spend most of my time as a lead. Dashboards allow us to broadcast velocity to stakeholders (like “Director Bob” or “VP Alice”) without them needing to dig through backlogs.

Here is my complete workflow for setting up the Velocity Widget.

1. Create or Select a Dashboard

Go to Overview > Dashboards.
Select an existing dashboard or click New Dashboard and name it (e.g., Team Eagle Overview).

2. Add the Velocity Widget

Click the Edit button at the top of the dashboard.
In the “Add Widget” search bar on the right, type Velocity.
You will see the Velocity widget (usually the one by Microsoft). Drag and drop it onto your canvas.

3. Configure the Widget Logic

This is the critical part. Click the Gear icon (Configure) on the widget you just added. You will see a modal with several fields. I will explain how I configure each one for maximum accuracy.

General Settings

Title: I usually name it specific to the team, like Team Eagle Velocity (Last 6 Sprints).
Team: Select the specific team you are tracking. Do not select the default “Project Team” unless you are a very small startup.

Work Items & Estimation

Backlog Level: Select Stories (for Agile/Scrum) or Requirements (for CMMI).
- Pro Tip: Do not select “Features” or “Epics” here. Velocity at the Epic level is rarely useful for sprint-by-sprint planning.
Aggregation: Select Sum.
Field: Choose Story Points.
- Alternative: You can choose Count of Work Items if you don’t use points (a #NoEstimates approach), but in my experience, the Sum of Story Points provides better fidelity.

Timeframe & Granularity

Number of Iterations: The default is often 6. I prefer setting this to 8 or 10. This gives me a broader historical trend, smoothing out anomalies like holidays (e.g., Thanksgiving or Christmas weeks).

Advanced: Planned vs. Late Work

There are checkboxes here that are often ignored, but I find them crucial for the US market where “meeting commitments” is a high-priority KPI.

“Show planned work for iterations”: Check this. It adds a “Target” bar to your chart. It tells you if your team has a habit of pulling in way more work than they can finish.
“Highlight work completed late”: Check this. This will shade a portion of the bar a different color if the item was marked “Done” after the sprint end date. This is a massive red flag for me as a coach—it usually means we are rolling over work or not closing tickets in real-time.

Click Save and then Done Editing.

Check out “How To Check Velocity In Azure DevOps” for complete steps with screenshots.

Reading the Velocity Chart: An Analyst’s Perspective

Now that we have the chart, how do I read it? I don’t just look at the number; I look for the story the number tells me.

The “Stable State”

Ideally, I want to see the green bars relatively level. If I see:

Sprint 1: 20 Points
Sprint 2: 22 Points
Sprint 3: 19 Points

This tells me I have a stable team. I can confidently tell my Product Owner, “We have a capacity of about 20 points next sprint.”

The “Yo-Yo” Effect

If I see this:

Sprint 1: 45 Points
Sprint 2: 10 Points
Sprint 3: 40 Points

This is a disaster. It usually means the team is “carrying over” work. In Sprint 1, they started 45 points worth of work but didn’t finish it. In Sprint 2, they finished the leftover work (getting “credit” for it) but didn’t start much new work. This makes velocity useless for planning because the average is meaningless.

The “Late Completion” Trend

If I see a large portion of the bar shaded as “Late” (from the setting we checked earlier), it indicates a process failure. The team is likely rushing to close tickets on the Monday after the sprint ends. As a Scrum Master, I would address this in the Retrospective.

Calculating Average Velocity for Forecasting

Azure DevOps provides the visuals, but sometimes I need a hard number for the “Forecast” tool. Here is how I calculate the Average Velocity to use for future planning.

I strictly use a Rolling 3-Sprint Average. Going back further than 3 sprints often includes outdated data (e.g., before a new team member joined).

The Formula

$$Average Velocity = \frac{V_{n-1} + V_{n-2} + V_{n-3}}{3}$$

Where $V$ is the velocity of the completed sprint.

Example Table:

Sprint Name	Points Completed	Status
Sprint 20	25	Normal
Sprint 21	18	Member on PTO (Thanksgiving)
Sprint 22	26	Normal
Average	23	(25+18+26) / 3

When I plan Sprint 23, I will set our capacity cap at 23 points.

Using the Forecast Tool

Once I have this average, I go back to the Backlog view.

Toggle View Options (top right slider icon).
Turn Forecasting “On”.
Enter 23 in the Velocity box.

Azure DevOps will instantly draw lines across my backlog, showing which stories are likely to fit in the next sprint and which will be pushed to the following one. This is the most powerful visual aid I have when negotiating scope with stakeholders.

Conclusion

Calculating Sprint Velocity in Azure DevOps is straightforward mechanically, but complex culturally. The tools—the Analytics view and the Velocity Widget—are robust and highly configurable. They provide the transparency needed to move from “guessing” to “forecasting.”

You may also like the following articles:

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.