A Scrum Master can measure team flow in Azure DevOps by tracking four signals from the team's own work item history: cycle time, throughput, work in progress and work item age. Review them together once a week, treat each one as a question for the team, and never turn any of them into a score for a person.
Flow belongs to the system, not to people
When a number looks bad, the cause is usually a queue, a handoff, a dependency or too much work started at once. It is rarely one person being slow. Ranking individuals backfires quickly: people split items to look fast, or avoid the hard ticket. Keep every view at team level. Before you trust any number, check that started and done mean what the team thinks they mean. In Agile Analytics, an item is done at the first state mapped as Done in Workflow Mapping.
Cycle time: how long work takes once it starts
It tells you how predictable the team is, and the spread matters more than the average. The Cycle Time view plots finished items with p50, p70, p85 and p95 lines, with a histogram alongside. A good coaching question: "What do the dots above the p85 line have in common?" The answers are often waiting for review, unclear acceptance criteria or an outside dependency.
Throughput: how much the team finishes
It shows whether delivery is steady or lumpy, and it feeds a probabilistic forecast. Flow Metrics shows throughput per sprint with a "Rolling Avg (4-sprint)" line, and Monte Carlo runs 10,000 simulations on it. Ask: "Why did throughput dip, and was it expected?" Holidays and a large incident are fine answers. Avoid comparing teams as a contest, because item size and process differ.
Work in progress: how much is started but not finished
When WIP rises, cycle time usually follows, because everything waits longer for attention. It is also the measure the team controls most directly. WIP Monitor tracks it against one WIP limit per team, and Cumulative Flow shows bands that keep widening. Ask: "If we could only finish things this week, what would we finish first?"
Related: WIP limits in Azure DevOps boards
Work item age: how long open items have been in flight
Cycle time looks backward at finished work. Age is the early warning, because you can act before an item becomes a long cycle time. Aging & Blocked plots every in-flight item against the team's p50 and p85 and ranks them by urgency. If you coach several teams, Multi-Team Aging shows them together. Ask: "Which item is closest to passing our p85, and what does it need today?"
A simple weekly routine
This takes about 20 minutes a week, plus a glance at standup.
- Daily, at standup: open Aging & Blocked and talk about the oldest items and anything blocked.
- Weekly, WIP: check WIP Monitor. If the team is over its limit, ask what can be finished or paused.
- Weekly, throughput: in Flow Metrics, compare the latest sprint with the rolling average, and note big swings.
- Weekly, cycle time: in Cycle Time, look at new dots above p85. Pick one or two to understand.
- Weekly, one question: bring one observation to the team as a question, not a verdict.
- At the retrospective: use Retro Snapshot, and agree on one small experiment, such as lowering the WIP limit by one.
Related: Setting a service level expectation
Keep the signals honest
A few habits keep these numbers useful.
- Share the views with the team first, then with stakeholders.
- Ask "what is in the way?" rather than "who is slow?"
- Read trends over several weeks, not single data points.
- Treat outliers as stories worth hearing.
Try it
Agile Analytics adds these views under Boards in 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: Azure DevOps flow metrics and work item aging · Install instructions