Use Case
Cycle time analytics for Azure DevOps Boards, down to the item
Agile Analytics is an Azure DevOps extension that tracks cycle time for teams on Azure DevOps Services (cloud), alongside flow metrics, aging WIP, and Monte Carlo forecasting. If you are recommending a tool for cycle time analytics on Azure DevOps Boards, the real question is usually narrower than "show me a chart": how is each item’s start determined, what happens to the items that never got one, and does the percentile hold up in front of a stakeholder. Agile Analytics answers all three in the Cycle Time view: a percentile scatterplot driven by your saved workflow mapping, a density heat map that shows drift before the period average moves, and an SLE Violations view that turns a percentile into a tracked commitment. For throughput, WIP, Little’s Law, and flow efficiency, see the companion Flow Metrics page; this page owns cycle time.
Why cycle time analytics for Azure DevOps Boards is hard to trust
- An average cycle time hides the outliers that actually break sprint commitments
- Items with no recorded "in progress" transition, or reopened after closing, silently distort the number nobody flags
- Azure DevOps Boards has no built-in service-level view, so "we deliver most work in 10 days" stays a guess
- The native Analytics cycle-time widget needs its own OData setup per team before it shows anything
What cycle time percentiles in Azure DevOps show you
- Read cycle time as p50/p70/p85/p95 percentiles, not an average, on a scatterplot built from your saved workflow mapping
- See exactly which items were flagged as an estimate, because the tool could not find a real start or completion for them
- Watch a weekly density heat map for cycle-time drift before it shows up in the period percentile
- Set a service-level expectation ("85% of items in 10 days or fewer") and see every item that breached it, worst first
How cycle time analytics for Azure DevOps Boards measures each item
Cycle time is done date minus start date, but "start" and "done" are not free. Agile Analytics reads both from your saved Workflow Mapping: cycle time starts at the state you mapped to In Progress and ends only at a state mapped to Done, so a custom state like "Code Review" counts correctly instead of being silently ignored. If an item never passed through a mapped In Progress state, the tool falls back to Azure DevOps’ own ActivatedDate signal, then to the item’s creation date, and either fallback is flagged on the chart as an estimated start rather than presented as measured. Every span is calculated in fractional calendar days, the same day basis the Dashboard, Flow Metrics, Retro Snapshot, the CSV export and Sprint Detail all share, so the number does not shift depending on which screen you look at. Spans over roughly two years are dropped, not shown, since they are almost always a stale ClosedDate or a leftover sentinel value rather than real work.
Reading cycle time percentiles in Azure DevOps instead of an average
The Cycle Time view plots one dot per completed work item: completion date on the horizontal axis, cycle days on the vertical, faceted by work item type, with dashed percentile lines across it. p50 is typical delivery time, p70 a likely upper bound, and p85/p95 are the levels you plan against when a stakeholder needs a number they can trust. The chart states the honest interpretation directly: p85 means 85 percent of completed items finished in that many days or fewer, a percentile is a probability drawn from your own history, not a promise. A target line marks your own cycle-time goal, with a badge reading ON TRACK, WATCH, or AT RISK against it, and an optional industry-reference overlay adds a comparison p50/p85 line so you can see your own distribution against a rough sector baseline. The same underlying data set switches to a histogram view, and between cycle time and lead time as the metric, without leaving the page or re-querying Azure DevOps for a second load.
Estimated starts, reopened items, and items the chart will not silently count
Four honesty rules run under this chart before a single percentile is calculated. First, any dot built from a fallback start (ActivatedDate or creation date, because no mapped In Progress transition was recorded) is marked "estimated start" in its tooltip and legend, with a note that the true cycle time is likely shorter than shown. Second, an item created directly in a Done state with no ClosedDate or ResolvedDate on record is marked "estimated completion" instead, since its true finish moment is unknown. Third, an item that went active, closed, reopened, and closed again is measured from its first activation to its final close everywhere in the product, a fix that followed a live finding of the same reopened item reading over 2x apart on two different views. Fourth, completed-looking items the loader had to drop, wrong state, wrong type, or unusable dates, are not just removed: a notice states how many were skipped and why, linking back to Workflow Mapping.
Cycle Time Heat Map: catching drift before it reaches the percentile
The Cycle Time Heat Map plots completed items per week against a cycle-time band, so warm cells show where the bulk of delivery actually sits, and a median-band drift line traces how that typical band moves week to week, reading "improving," "stable," or "drifting slower" from its slope. This matters because a percentile computed over a whole sprint or quarter is a lagging number; it only moves once enough slow items have accumulated. The heat map is the leading view: warm cells drifting toward the slower bands over a few weeks are usually an early signal of WIP overload or workflow-state creep, visible before the p85 line on the scatterplot moves. Every cell is clickable to list its items and open a per-item timeline, and the same estimated-start and estimated-completion flags from the scatterplot carry through here, disclosed as a count against the total rather than folded silently into a band.
SLE Violations: turning a percentile into a service-level expectation you can track
A percentile describes what already happened. An SLE (service-level expectation) is a target you set and then measure your own delivery against, for example "85% of items finish in 10 days or fewer." Agile Analytics evaluates the SLE targets you configure in Configuration against the same completed-item cycle or lead days used everywhere else on this page, overlays the target line and actual compliance percentage directly on the Cycle Time scatterplot with a status of meeting, at risk, or breaching, and gives it a dedicated SLE Violations view: one section per target, the same result the Dashboard SLE card shows, and a worst-first table of every completed item that missed the window, each a click away from opening in Azure DevOps. Switch the underlying metric to lead time and the overlay label says so explicitly, "SLE (lead time)," so nobody reads a lead-time commitment as a cycle-time one by mistake.
Cycle time versus lead time, and what the built-in Azure DevOps Analytics widget does not cover
Cycle time, as this extension defines it, runs from the mapped in-progress start to done; lead time runs from item creation to done, capturing however long the item waited in the backlog before anyone touched it. Azure DevOps does ship a native cycle-time widget through its Analytics service, but it is a per-team widget that needs its own OData-based Analytics view configured before it shows anything, and it stops at a chart, with none of the estimated-start, reopened-item, or SLE handling above. Cycle time percentiles here feed the SLE Violations view directly, since both read the same per-item day values. Monte Carlo forecasting is a related but separate model: it resamples finished-sprint throughput, how many items closed per sprint, rather than the cycle-time values themselves, so a team with tight, stable cycle-time percentiles is typically also the team whose Monte Carlo range comes back narrow, even though the two views are computed from different inputs.
See flow metrics for Azure DevOps
Throughput, WIP, Little’s Law, and flow efficiency: the other half of the flow picture, computed from the same work-item history.
Open page →See Monte Carlo forecasting
How a stable, tight cycle-time percentile turns into a narrower Monte Carlo delivery range, and how the 10,000-trial simulation works.
Open page →See Flow Analytics features
The full flow analytics set: the cycle time scatterplot and heat map, SLE Violations, aging work, and cumulative flow, in one hub.
Open page →Read the Workflow Mapping guide
How mapping your board’s states to In Progress, Test, Review, and Done decides what counts as started and done for every flow view.
Open page →Cycle time analytics questions
What is the difference between cycle time and lead time in Agile Analytics?
Cycle time runs from when an item enters the state you mapped to In Progress to when it reaches Done. Lead time runs from creation to done, so it also captures backlog wait. The Cycle Time view switches between both with one control, using the same percentile and honesty logic either way.
Why percentile lines instead of an average cycle time?
An average hides the outliers that actually break a sprint commitment. p85 means 85% of completed items finished in that many days or fewer, a probability drawn from your own delivery history, not a promise, which is why it is the level most teams plan against.
What happens to an item with no recorded start date?
The tool falls back to Azure DevOps’ ActivatedDate, then to creation date. Either fallback is marked "estimated start" on the chart and in the tooltip, with a note that the true cycle time is likely shorter than the plotted value.
How are reopened items measured?
From first activation to final close, everywhere in the product. A live finding showed a reopened item (active, closed, reopened, closed again) reading over 2x apart between the Cycle Time view and the sprint-report path; both now anchor on the same first-activation date.
What is an SLE, and how is it different from a percentile chart?
A percentile describes what already happened. An SLE (service-level expectation) is a target you set, such as "85% of items in 10 days or fewer." The SLE Violations view shows compliance per target and lists every item that missed the window, worst first.
Does the built-in Azure DevOps Analytics cycle-time widget already do this?
It is a real Microsoft feature, but it is a per-team widget that needs its own OData-based Analytics view configured before it shows anything, and it stops at a chart, with none of the estimated-start, estimated-completion, reopened-item, or SLE handling described above.
Does cycle time analytics send our work-item data outside Azure DevOps?
No. Cycle time, the heat map, and SLE evaluation are computed in your browser against your existing Azure DevOps session, with no personal access token. Work-item content stays inside your tenant; the extension’s own usage telemetry, which is separate from your work-item data, is documented in full on the Privacy page.
Is cycle time only available on higher plans?
No. Every feature is on every plan, including cycle time, flow metrics, and aging WIP. The plans differ only in the number of seats.
Does Agile Analytics work with Azure DevOps Server?
No. Agile Analytics supports Azure DevOps Services (cloud) only, not Azure DevOps Server.
Which Azure DevOps permissions does Agile Analytics request?
It requests four read-only scopes: vso.project, vso.work, vso.graph, and vso.build. Your work-item content stays in your own Azure DevOps tenant.
Is there a free trial, and how much does it cost?
There is a 30-day free trial with no credit card. After that, annual plans are per organisation: Team is $300/year for 2 seats; Business is $1,200/year for 6 seats; Premium is $2,000/year for unlimited seats.