Your Azure DevOps Cycle Time widget and your Power BI report disagree because they almost never define cycle time the same way. Each one decides where the clock starts, where it stops, which date it reads, what happens when an item reopens, and how the result is summarised. Change any one of those and the number moves. Neither figure is wrong until you know which definition it uses, and once both are written down, the gap usually explains itself.
What the Azure DevOps widget measures
Microsoft documents the rule. According to the Configure lead time and cycle time widgets article, cycle time runs from the first time an item enters a state in the In Progress or Resolved state category to the final time it enters a Completed state category. Lead time runs from creation to Completed. For a reactivated item, the widget counts the whole span, including the time it sat in Closed before it was reopened.
- It reads state categories, not your team's idea of done. If your process has Resolved before Closed, the widget clock keeps running through Resolved until Closed.
- Its headline is average days over the period you configure (a rolling number of days or a start date), drawn with a moving average and a standard deviation band.
- The Analytics Cycle Time Days field that many Power BI reports use follows the same category rule, per the Analytics metadata reference.
What a Power BI report measures
Whatever its author built. Three builds are common, and each one disagrees with the widget for its own reason:
- Cycle Time Days from Analytics. Same rule as the widget, so a gap usually comes from filters, the date window or the statistic, not the definition.
- Closed Date minus Activated Date. Microsoft describes Activated Date as the date an item was activated or reactivated, so on a reopened item this measures only the last stretch of work. It also ignores any state your team treats as done before Closed.
- State Change Date. It records when the State field last changed, not when the item entered the state you care about, so "when did this reach Ready for Deploy" quietly becomes "when did this last change state".
Five decisions that move the number
Line up the two tools against these five, in this order. Most gaps are explained by the first three.
- Where the clock starts. A state category, a named state, the first move out of New, or creation? Starting at creation turns cycle time into lead time, so an item that sat four months in the backlog looks four months slower.
- Where the clock stops. Resolved, Ready to Release, Closed? If items wait a week for a release train, that week is cycle time in one tool and not in the other.
- Which date is read. The full state history, or a single date field such as Closed Date, Activated Date or State Change Date?
- What happens on a reopen. Does the clock run from the first start to the final finish, or restart from the reopen?
- How it is summarised. Average, median or a percentile; calendar or working days; whole or fractional days; which item types, area paths and dates are included. Cycle time is almost always skewed, so an average and a median can sit far apart on the same items.
Then pick the five items where the tools disagree most, open their history, and see which rule explains the difference. It is usually a reopen, a long wait in a late state, or an item with no recorded start.
How Agile Analytics answers it: Workflow Mapping
In Agile Analytics the answer to "where does cycle time start and stop" is not buried in a formula. It is your Workflow Mapping, under Configuration, where an admin decides which of your states are In Progress and which are Done. The Cycle Time view and How These Metrics Work both print the rule in plain words:
- "Cycle time runs from the first move into an In Progress state to the first move into a Done state, in calendar days with decimals."
- "Moves between Done states add no time." Map Ready to Release as Done and the clock stops there, even if the item waits days before Closed.
- "Time after a reopen is included." A reopened item takes its later finish, so the span covers the rework.
- "We measure states, not board columns." A Power BI report built on board columns will differ for that reason alone.
When an item has no recorded move into an In Progress state, the start falls back to its Activated Date, then to its creation date. The view says how many items that affected ("N of M items had no recorded start, so their cycle time is measured from the creation date"), so an estimate never passes for a measurement.
Where the two rules differ
Side by side, the two rules agree on reopens and differ on the start, the stop and the headline:
| Decision | Azure DevOps widget | Agile Analytics |
|---|---|---|
| Start | First entry into an In Progress or Resolved category state | First move into a state you mapped as In Progress |
| Stop | Final entry into a Completed category state | First move into a state you mapped as Done (in the final run of Done states) |
| Reopened items | Whole span, first start to final finish | Whole span, first start to final finish |
| Headline | Average days, moving average | p50, p70, p85 and p95 lines |
Two consequences follow. If your team maps Resolved or Ready to Release as Done, Agile Analytics stops the clock earlier than the widget, by however long items wait there. And comparing a p50 with an average will show a gap even when both tools agree on every item.
One rule on every view
Inside Agile Analytics the same derivation feeds the Cycle Time view, the Dashboard, Flow Metrics and the other views that show cycle time, so a given item has the same number of days everywhere. Cumulative Flow follows the same mapping too: its completions come from the first move into a Done state, not from the Azure DevOps closed date. The Cycle Time view also has a Lead switch, measured from creation to the same Done move, if you need lead time on the same footing.
Related: Cycle time scatterplot and histogram · Workflow Mapping for accurate analytics · Azure DevOps state categories
If Power BI stays your source of truth
Agile Analytics does not connect to Power BI or feed it data. It runs in your browser inside Azure DevOps, against the Azure DevOps REST API with read-only access. If Power BI is where your organisation reports, write the five decisions above into the report description and make the widget, the report and your team agree on them. If the in-product numbers are enough, see Azure DevOps Analytics vs Power BI for what each approach costs to run.
Try it
Install Agile Analytics, check your Workflow Mapping, open Cycle Time, and compare it with your current report using the five decisions above. 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