What’s in 6.26
This is our biggest release of the year, and all of it lands in the Measure group, in every plan from Starter up. DORA Metrics brings the four industry-standard delivery metrics inside Azure DevOps, computed from your own work items and pipelines — no exports, no third-party connectors. Exec Report turns delivery health into a stakeholder-ready summary you can print to PDF, or have emailed automatically to the people who never open Azure DevOps. And Investment Allocation answers the question every planning conversation circles back to: how much of our finished work was features, how much was bugs, how much was maintenance — and how much arrived unplanned? One thing is different about this update: because DORA’s deployment metrics need to read your pipeline runs, Azure DevOps will ask an organisation admin to approve the extension once. It is a read-only permission, it is the only change to what the extension can access, and — as always — your data never leaves your Azure DevOps organisation.
DORA Metrics, natively in Azure DevOps
Deployment frequency, lead time for changes, change failure rate, and time to restore — the four measures engineering leaders are asked about most, computed inside Azure DevOps from the data you already have. Deployment frequency and build failure rate read your completed pipeline runs; lead time and time to restore are computed from your work items’ own history, clearly labelled as work-item proxies with their sample sizes, so you always know what a number is based on. Pick a 14, 30, or 90-day window and the view recomputes on the spot. If your organisation hasn’t granted the pipelines permission yet, the work-item metrics still work — the pipeline cards simply explain what would unlock them.
Exec Report: board-ready in one click
The Exec Report view assembles a delivery-health summary for the teams you select — commitment and delivery, scope health, flow, and plain-English insights — built for the “how are we doing?” question, and requested by teams who report upward. Open the print view and you have a PDF for the meeting; Copy Summary and Export CSV are there when you want the numbers in another document instead.
Scheduled report emails, with consent built in
You can also deliver that report automatically — weekly, monthly, daily, or at the end of each sprint (Configuration → Scheduled Reports). Recipients get a confirmation email first and receive nothing until they accept; every digest carries a one-click unsubscribe; and the report content itself is never stored on our servers — it is computed inside your Azure DevOps organisation, relayed to the confirmed recipients, and discarded.
Investment Allocation: where the work actually goes
For each team, completed work from the last 14, 30, or 90 days is classified into features, bugs, and maintenance and shown as a percentage split — plus an unplanned-share figure for work that arrived and was finished inside the same window. Tasks count as maintenance, and anything tagged tech-debt, refactor, chore, or similar counts as maintenance regardless of type, so a Bug fixed as part of a cleanup lands where it belongs. If your process uses work item types the view doesn’t recognise, they’re shown explicitly as “unclassified”, never silently dropped — you always see the whole picture. There is nothing to configure; it works from the work items you already track.
6.26.2: Cycle Time that explains itself
A patch release right behind 6.26 makes the Cycle Time chart more transparent about what it is (and is not) showing. If stories that look finished are not counted — because their state is not mapped as Done, their work item type is not mapped to a chart bucket, or their dates are unusable — the view now says so, with the count, the reason, and a shortcut to review your Workflow Mapping. And when a story never passed through a state mapped as In Progress, its cycle time can only be measured from the creation date: those dots are now drawn with a dashed outline, flagged in the legend as estimated starts, and the tooltip explains that the true cycle time is likely shorter. No numbers changed — every point, percentile, and histogram is computed exactly as before. The chart just tells you the whole story now.
About the one-time permission approval
Azure DevOps requires organisations to re-approve an extension whenever it requests a new permission — a good policy, and this release triggers it. The new permission is Build (read): read-only access to pipeline runs, used solely to compute DORA deployment frequency and build failure rate. Nothing else about the extension’s access changes, and no pipeline data (or any data) leaves your Azure DevOps organisation. An organisation admin will find the approval under Organization settings → Extensions — Agile Analytics shows a review notice; open it and choose Authorize. Until that happens, your organisation simply stays on its current version: nothing breaks, nothing changes, and every setting, license, and workflow mapping is preserved through the update.
Updating
After an organisation admin approves the permission (Organization settings → Extensions → Agile Analytics → Authorize), the update applies automatically — there is nothing to install. The first time you open the hub afterwards, the What’s New popup shows the 6.26 highlights once and then dismisses. Questions or ideas? Ask Henry from the top bar or the Help & Support page — we reply personally within 24 hours.