Most teams do not need more Azure DevOps metrics. They need to know what each number is built from, so they can trust it or question it. This post is a map: the metrics worth tracking in five groups (flow, sprint, delivery, forecasting and stability), the Azure DevOps data behind each one, where it shows up in the Agile Analytics hub, and the guide that covers it in depth. One setting sits underneath all of them, Workflow Mapping, so it gets its own section at the end.
Flow metrics: how work moves
Flow metrics describe how work moves through your process, whether or not you run sprints. Almost all of them are built from one source: the state history of each work item, meaning which state it moved into and when.
- Cycle time: from the first move into an In Progress state to the first move into a Done state, in calendar days with decimals. Shown in Cycle Time (Plan group), a scatterplot of completed items with p50, p70, p85 and p95 lines and a Scatter / Histogram switch. When someone asks how long a story takes, quote a percentile rather than an average.
- Lead time: from the day the item was created to the first move into a Done state, so it includes time waiting in the backlog. The Cycle Time view switches between Cycle and Lead, and Flow Metrics shows Avg Lead Time.
- Throughput: how many items finished. For a sprint, Agile Analytics counts the sprint items that are in a state mapped as Done. Flow Metrics shows "Throughput, reliability, cycle time, and lead time across recent sprints", with a "Rolling Avg (4-sprint)" line.
- Work in progress (WIP): items started but not finished. WIP Monitor compares it with one WIP limit per team, and items in the Removed state do not count. Alerts can go to a Slack or Microsoft Teams channel through a webhook, set per team under Configuration, WIP Rules.
- Work item age: how long each unfinished item has been in flow so far. Cycle time only exists once an item finishes; age warns you before that. Aging & Blocked plots every item in flow against the team p50 and p85 and ranks them by urgency. Multi-Team Aging does the same across several teams.
- Flow efficiency: touch time divided by cycle time. Time in states mapped as In Progress, Test or Review counts as active; time in queued or waiting states counts as wait. A state whose name signals a queue, for example anything containing "ready for", "ready to", blocked, waiting, on hold, awaiting, pending or queued, counts as wait even if it is mapped as active. Shown in Flow Efficiency.
Related: Cycle time scatterplot and histogram · Flow metrics and work item aging · Flow Analytics: cycle time and WIP · WIP limits in Azure DevOps · Aging work items at standup · How to read a cumulative flow diagram
Cumulative Flow ties them together
Cumulative Flow draws one band per stage over time, so a widening band shows a queue building up. Its completions follow your Workflow Mapping, not the Azure DevOps closed date, so it agrees with throughput.
Sprint metrics: did we do what we planned?
Sprint metrics depend on the sprint dates and on which items sat in the sprint on each day, so they are built from iteration history as well as state history. Agile Analytics counts items, not points, for all three below.
- Commitment reliability: the share of committed items completed by the end of the sprint. The commitment is what the sprint holds at the end of its first day, completion allows 24 hours of grace after the sprint ends, and Removed items count on neither side. The Sprint Summary card reads "Delivered 8 of 10 committed" and says how many were not delivered; Delivery Signals shows the trend across finished sprints, marked Healthy, Watch or Low.
- Scope change: work added to or removed from the sprint after the commitment. The Scope Change tile on each Sprint Summary card counts items added after Day 1 and items removed from scope after Day 1.
- Carryover: for a finished sprint, an item that was in the sprint at the end of at least one sprint day, was not done when the sprint ended or when it left, and either stayed in the sprint or moved straight into the next one. Work moved back to the backlog unfinished is removed scope, not carryover. A running sprint shows a dash, because carryover is counted when the sprint ends. Sprint Summary, Sub-teams, the Dashboard, Delivery Signals and the Exec Report use this rule; Team Benchmarks and Retro Snapshot still use an older measure, committed items not finished by sprint end.
Related: Sprint reports: scope and carryover · How carryover is counted · Reducing sprint carryover · Azure DevOps velocity chart · Azure DevOps burnup chart
Velocity and burnup
Two Dashboard cards, both off by default under Customize, cover the classic sprint charts: Sprint Velocity, a table of the last six sprints with the running one marked in progress, and the card labelled Sprint Burndown, which draws a Sprint Burnup with Scope, Ideal and Completed lines.
Delivery metrics: DORA
The four DORA metrics measure delivery from commit to production. In Agile Analytics they come from two sources, and the DORA Metrics view labels which is which. Pipeline data is read with a read-only build scope.
- Deployment frequency: from your Azure Pipelines runs.
- Lead time for changes (work-item proxy): from Activated to Closed on work items.
- Change failure rate (defect proxy): bugs opened compared with items delivered.
- Time to restore (bug-close proxy): bug Created to Closed.
Related: How to measure DORA metrics in Azure DevOps · Change failure rate from deployments
Why the proxies are labelled
Work items cannot see a deployment, so three of the four are approximations, and the labels say so. When an admin turns on linked deployments under Configuration, DORA Metrics, the view adds pipeline-based lead time and change failure rate cards beside them. The Exec Report carries the same figures in its "Delivery performance (DORA)" section.
Forecasting: answers built from throughput
A forecast is not a metric to track over time. It is an answer built from one, mostly throughput, so it inherits every counting rule above.
- Monte Carlo (Plan group) resamples finished-sprint throughput in 10,000 trials and answers "How many?" by a date or "When will it finish?" for a number of items, at 50%, 70%, 85% and 95%.
- The Dashboard "How many?" Forecast card asks how many items are likely to finish in the next 30 days.
- Next Sprint Planning combines capacity with the last finished sprints into one recommendation for the planning meeting.
Related: Monte Carlo forecasting in Azure DevOps · The Forecast tool vs Monte Carlo · Next Sprint Planning guide
Stability: is the change real?
A trend line tells you a number went up. It does not tell you whether that means anything. Process Behavior draws an XmR chart, sprint by sprint, for Throughput, Cycle Time (p50) or Flow Efficiency, with natural process limits (UCL and LCL) calculated from your own data. Points outside the limits, runs of 8 on one side of the centre line, or 3 of 4 points beyond two sigma are flagged. Anything else is routine variation: check it before reacting to one bad sprint, because a retro action aimed at noise changes nothing.
Workflow Mapping decides every number
Every metric above asks the same question first: which stage does each state belong to? Azure DevOps lets each process name its states differently, and "Ready to Release", "In Review" or "Blocked" mean nothing to a calculation until they are mapped. In Agile Analytics, first-time setup reads your project states, and an admin can check where each one belongs under Configuration, Workflow Mapping (New, Queued, In Progress, Test, Review and Done). That mapping decides:
- Where cycle time starts (the first move into an In Progress state) and stops (the first move into a Done state). Map Ready to Release as Done and the time items wait there for a release is no longer cycle time.
- What counts toward throughput, Cumulative Flow completions and carryover.
- Which time counts as active and which as waiting in flow efficiency.
Related: Workflow Mapping for accurate analytics · Workflow Mapping docs · Azure DevOps state categories
A wrong mapping does not raise an error
It produces a plausible number that is wrong, and that number then feeds your forecasts. Agile Analytics measures states, not board columns, and flags states that are not mapped. Check the mapping whenever your process changes. How These Metrics Work, under Tools, explains each metric inside the hub.
Try it
Agile Analytics adds these views as a hub in each Azure DevOps project. It runs in your browser against the Azure DevOps REST API with read-only access, so it never changes your work items, and it needs no Power BI and no personal access token. It supports Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and everyone in the organisation has full access while it runs.
Related: Install instructions · Pricing