Release notes

Version 6.63.5October 2026

A sprint that has ended now counts as finished in every view, Monte Carlo can size a backlog from an Epic, and many numbers, dates and labels now agree from view to view.

Numbers that can change: a sprint whose end date has passed now counts as finished in every view, even while Azure DevOps still calls it the current sprint because no newer sprint exists. Averages and forecasts that used to leave it out now include it, so they can move, usually down when that sprint delivered little: Dashboard, Sprint Velocity, Flow Metrics, Delivery Signals, Monte Carlo, Retro Snapshot, Sprint Capacity, Team Leaderboard, Cycle Time and the Sub-teams forecast. Views that show the current sprint still open on it, and now say "· ended Oct 16" instead of "(Current)", "(in progress)" or "so far". Next Sprint Planning says that no next sprint is defined yet instead of offering the ended sprint to plan. The Monte Carlo view with several teams, the free Monte Carlo Sprint Forecast and the Sprint Forecast dashboard widget work as before.

Exec Report: it now opens on the sprint that just ended and says how long ago it ended ("ended 2 days ago"), on screen and in the printed report. When nothing was committed the headline says "No commitment baseline for this sprint", the team card shows a dash for Commitment reliability and Scope churn instead of 0% and 100%, and "Avg reliability (recent sprints)" shows a dash instead of 0%. A team card whose Throughput is higher than Delivered says how many items were completed but not against the commitment. The forecast says its window in days, "in the next 4 weeks (28 days)", and if the forecast and risk figures take longer than 15 seconds the headline says "Forecast unavailable right now." instead of loading forever. "Open items older than the p85 cycle time" now also counts still-open work carried over from the previous sprint.

Exec Report: Email draft is now Copy email text. It copies a ready-to-send email, a subject line and the summary, that you can paste into a new email in your email app, and the report no longer goes blank. The support and billing email addresses now show with a Copy button. On the screen shown when a trial has ended, Copy message replaces Email this message.

Dashboard, "How many?" Forecast: it now uses the same 6 finished sprints as the Monte Carlo view. While a sprint was running it used only 5, so for teams with a running sprint its numbers can move to match Monte Carlo.

Monte Carlo, When will it finish?: under Backlog from, choose An Epic or Feature to pick one of the Epics Epic Analytics shows, or one of its Features, by title or ID. The backlog becomes its stories not done yet, counted the same way as the Epic Analytics row. With several teams selected, enter the backlog as a number. The Completion Timeline’s "Today" now shows your own date for anyone east of UTC, and in Weeks a note says the forecast moves one whole week at a time from today.

Flow Metrics: "Median Cycle Time" is now a true median, the average of each finished sprint’s median cycle time, the same figure Delivery Signals shows under the same name. The figure may shift slightly, usually down. The Little’s Law card now works for teams with imported history. The Flow Efficiency view says what each side of the 15 to 40% band means.

Multi-Team Aging: "Blocked" used to mean 5 days or more with no state change. That rule is now called "Stalled 5d+", and "Blocked (recorded signal)" counts the items your Blocked signals mark as blocked. The risk score and "Teams At Risk" use the recorded count, so risk scores drop for teams with work that is stale but not blocked. Aging & Blocked now includes still-open items carried over from the previous sprint.

Sprint Summary: for teams whose history was imported, for example from Jira or a CSV file, a story that was in the sprint on day one and moved out later now counts as committed. Commitment reliability can go down for these teams, and the moved story shows as carried over. Teams with their full Azure DevOps history see no change.

Reliability colours: the Commitment colours in Sprint Velocity and the Avg Reliability tile in Flow Metrics now follow your reliability target, as Delivery Signals does. With the default target, green is from 85%, amber from 70% and red below 70%. Admins set the target in Configuration → Enterprise, under Dashboard thresholds.

DORA: Build failure rate now says what it is based on, for example "4 of 4 completed runs failed", and shows "No data" when no run finished.

The Dashboard fits a phone screen without sideways scrolling, and in Customize on a phone the "Hidden" tag no longer covers a widget’s checkbox.

Privacy wording is clearer: the Industry Benchmarks snapshot is linked only to your organisation ID, and usage telemetry events are linked to your organisation and user ID, never work item content, names or titles. A few texts called these anonymous; they now say exactly this. Nothing that is sent has changed.

In-product help and descriptions across the app were checked against how the numbers are actually worked out and corrected where they differed, for example Cycle Time, DORA, Aging, Next Sprint Planning and Little’s Law. A sprint with a damaged or open-ended date in Azure DevOps no longer stops a team’s views from loading.

Version 6.63.1October 2026

Monte Carlo can forecast from weekly throughput for teams that do not run sprints, and Epics in Epic Analytics now show a burn-up when you open them.

Monte Carlo can now forecast from weekly throughput, for teams that do not run sprints. Teams that use sprints see the same forecast as before unless they choose Weeks. Under Forecast from, choose Weeks, pick a History of the last 8, 12 or 26 complete weeks, and run the forecast. Weeks run Monday to Sunday (UTC) and the current week is not counted. It counts every finished item in the team’s area, including items that were never in a sprint, using the team’s Workflow Mapping; items that were reopened or removed since are left out, and the Item Types filter applies. A note under the result says which weeks were used and anything that was left out. If more than 1,000 items finished in the window there is no forecast, so choose a shorter window. When a team has no past sprints, Monte Carlo now offers Forecast from weekly throughput.

Open an Epic that has Features in Epic Analytics to see its burn-up: stories done over time against today’s total, with the same 50% and 85% landing dates as the table. The flat line is today’s total, not a history of how the scope changed. Done stories that have no close date in Azure DevOps are not plotted, so the chart can show fewer done stories than the Stories column, and the chart says how many.

Version 6.62.1October 2026

See each sub-team next to its parent in one new view, and choose whether a parent team’s numbers include its sub-teams’ work.

If your team has sub-teams, there is a new Sub-teams view right after Dashboard. It shows one row for each sub-team, plus the parent’s own items and a total, with every item counted once. For each row you see items, done, in progress, blocked, older than usual (the same rule as Aging & Blocked) and cycle time. For each sub-team you also see committed, delivered, kept %, added, carryover, a delivered-per-sprint trend for the last 6 sprints, and a next-sprint forecast: 85% likely at least N items, from the last 12 sprints. The view has a Progress tab (items, done, in progress, blocked, older than usual, cycle time) and a Delivery tab (committed, delivered, kept, added, carryover, trend and forecast). The Switch button opens that sub-team’s Dashboard, and you can export the view to CSV. Teams without sub-teams do not see the view.

Parent teams also get a new switch in the sidebar under the team picker: Sub-teams’ work: Included (2 sub-teams) or Not included. It is set to Included. Included means the parent’s views count the sub-teams’ work once, the way Azure DevOps shows the parent’s backlog. Not included means every sprint view shows the parent’s own work only. The setting is shared by the whole team, and only Agile Analytics admins can change it. Each change is recorded in the admin activity log under Configuration → Access Control. Every sprint view now says which one you are looking at: Showing Team A + 2 sub-teams, or Showing Team A only, with a Change link for admins. The line describes the team that view is showing, including a team picked in the view’s own team list, and is left out when a view shows all teams or several at once. Sprint Summary and Exec Report show it for each of their teams. The Sprint Summary and Exec Report CSVs gain a scope column for these teams.

Numbers change for parent teams that have sub-teams in their area, with the switch on Included. Sprint Summary’s committed, added mid-sprint, removed, carryover and commitment reliability, and Cumulative Flow, now count the sub-teams’ work too, the same way Dashboard, Aging, Cycle Time, Monte Carlo and the other views already did. Before, sub-team items were missing from committed but counted as added, so scope change looked too high. Committed goes up and added goes down; carryover and commitment reliability now include the sub-teams’ work, so they describe the whole team. If you want the old own-work-only picture everywhere, turn the switch to Not included.

Dashboard commitment figures for these parent teams no longer depend on which view you opened first.

Monte Carlo now warns you when a parent team and its own sub-teams are selected together, because the parent already includes them.

Teams without sub-teams, project default teams, and parent teams whose area does not include their sub-teams’ areas see no change. Azure DevOps dashboard widgets are unchanged.

Exec Report and Cycle Time can now include teams from other projects. Use Add Team in Exec Report, or choose Compare teams across projects in Cycle Time. Each team is counted with its own project’s Item Types and Workflow Mapping. If you do not add a team from another project, both views read and compute exactly as before.

The Sprint Burnup card no longer gives items without an estimate a made-up size. In Story Points mode an item with no estimate now counts as 0 points, and the card tells you how many items that is. Your Story Points totals go down if your team leaves items unestimated. Items mode is unchanged, and no other view is affected.

Privacy: when a team has sub-teams, we now record one anonymous usage signal saying it has them and roughly how many (1, 2-3, 4-7 or 8+). We never record team names. The existing opt-out at Configuration → Privacy covers it.

Version 6.60.1October 2026

Feature and Epic Analytics show when work started and when it ends, and two figures now count only work that is really in progress.

Feature Analytics and Epic Analytics have two new columns after State. Started is the date the first child item became active. End is the date it was delivered, otherwise its Target Date, otherwise our forecast for Epics, and says which one it is. Each card on the Epic roadmap shows the same two dates. No other figure in these views changes.

An item that was started and then set to Removed kept counting as work in progress. The WIP Monitor, the WIP chart on Flow Metrics and the Dashboard WIP figure now leave it out from the moment it was removed, so these figures can go down if your team removes started work. Before it was removed, it still counts.

An item that was closed and then reopened was aged in Aging & Blocked as if the closed period were work: active 5 days, closed 20 days and reopened 2 days ago showed 27 days. It now shows 7, the days it was actually worked. Multi-Team Aging and the aging risk in Exec Report count it the same way. Cycle Time is unchanged and still measures from the first start to the final finish.

Dashboard widget labels, team names and secondary text follow the Azure DevOps theme, so they are easy to read on the dark theme.

Version 6.59.4October 2026

Workflow mapping is safer and clearer, and dashboards load faster. Your numbers are unchanged.

Saving Workflow Mapping is protected. If another admin saved changes after you opened the page, your save is stopped with a clear message and nothing is overwritten. Workflow suggestions are now shown only to admins, name the project they are about, and first-time setup only includes states that exist in your project. Existing mappings are not changed.

Configuration → Workflow Mapping marks an entry that is not a state in your project’s current process, so you can see at a glance what applies to your workflow. Nothing is changed for you.

Cycle Time, Aging & Blocked and Cumulative Flow now tell you when your work item history contains states that are not mapped, with a link to Workflow Mapping. Cycle Time also shows how many items had no recorded start and explains how cycle time is measured.

Dashboards load faster because the same data is no longer requested several times. First-time setup shows its progress while it reads your workflow, and boards that Azure DevOps reports as out of date are no longer used to order stages.

Version 6.59.3October 2026

Aging & Blocked follows your team’s real workflow in board order, and dashboard widgets can pick a team from any project.

Aging & Blocked drew a lane for every stage in your workflow mapping, including stages your project does not use, so a team working New, Active, Resolved, Closed saw empty lanes such as “Committed”, “Ready To Test” and “Ready To Review”. The chart, the stage list under its title and Aging Trend by Sprint now show one lane for each in-progress state your team really uses, in the order of your team’s board. A team with more than eight in-progress states keeps grouped lanes so the chart stays readable. Days in flow, the p50 and p85 lines and “over p85” are unchanged.

On narrower screens, the item list in Aging & Blocked could be wider than its card. The page then scrolled sideways and cut off the left edge of every card. The rows now fit their card and wrap onto a second line when space is tight.

In a dashboard widget’s Configure panel, the team list only covered your first five projects, so in larger organisations the dashboard’s own project could be missing. It now lists every project, starting with the dashboard’s own. Picking a team also updates the preview straight away, where it used to show “Select a team” until you saved.

Version 6.59.1October 2026

Teams with no sprints get a clear Dashboard message, and the cycle-time figure has one name on every view.

On the Dashboard, a team with no sprints selected in Azure DevOps saw “We couldn’t find any completed items” and a prompt to verify Workflow Mapping, although the mapping was fine. The Cycle Time card and the Cycle Time view now say the team has no sprints yet and show where to select them: Project settings → Team configuration → Iterations. Teams that have sprints see no change.

Flow Metrics called its cycle-time figure “Avg Cycle Time” while Delivery Signals called the same figure “Median Cycle Time”. Both now say “Median Cycle Time”, the average of each sprint’s median cycle time. The numbers are unchanged.

In the Flow Metrics and Delivery Signals CSV exports, a sprint with nothing committed, or with no flow data, showed 0% for commitment reliability, carryover or flow efficiency, where the views show a dash. Those cells are now empty, so a spreadsheet no longer reads them as a missed commitment.

Version 6.59.0October 2026

Exec Report becomes a one-page summary you can share, the Sprint Forecast widget is free for every organisation, and commitment reliability counts only your own team’s work.

Exec Report now opens with a one-page summary for leadership: a status (On track, Watch or At risk), an 85% forecast of how many items will finish in the next four weeks, the delivery trend over the last six sprints, the main risks (carryover, scope churn, items aging past the usual cycle time, bugs opened versus closed) and DORA figures when your pipelines provide them. Detail for each team follows. Use Share to save it as a PDF, copy the summary or open an email draft. The summary is built in your browser and is not sent to us.

Scheduled Reports in Configuration has been removed, together with the emailed report it set up, which was delivered through our service. For figures on a regular schedule, the Delivery Digest pipeline runs in your own Azure DevOps. Data & Privacy now lists two things that reach us instead of three.

The Sprint Forecast dashboard widget is free for every organisation, with or without a trial or subscription. Add it from the widget catalog under “Agile Analytics”. The other Agile Analytics widgets and the extension itself still need a trial or a subscription.

In sprints shared by several teams, which is the Azure DevOps default, commitment reliability counted other teams’ items still in the sprint as work your team committed to and then moved out. Reliability read too low, and moved-out and carryover too high. These figures now count only your own team’s work, so affected teams will see reliability go up and carryover go down. This also changes those figures in Exec Report. Saved settings are unchanged.

GitHub retired its older Copilot metrics API in April 2026. Since then AI Metrics, the AI Adoption widget and Test Connection showed a misleading “not enabled” message, and AI Metrics showed only sample data. They now read GitHub’s Copilot usage reports for the latest 28 days, and error messages name the actual problem, such as an invalid token or a missing permission. Chat active users shows 0 because GitHub’s reports have no daily figure for it.

AI Metrics saved the sample report as if it were your data, and AI Impact then read it. Only live reports are saved now. Anything already saved is left as it is.

“Auto-detect from ADO” in Configuration → Item Types now follows Azure DevOps’ own work item categories, so renamed and custom requirement and bug types are picked up correctly. On projects using the Basic process, Issue is detected as Planned Work rather than Bug. Auto-detect only fills in the form: nothing changes until you press Save Item Types.

New Scrum projects now count the Committed state as In Progress, because work in Committed has started. If your Workflow Mapping lists a state under Queued that Azure DevOps treats as In Progress, a notice offers to move it with one click. Nothing changes until you press Save changes.

On projects using Azure DevOps’ Basic process, the Setup readiness check, the Sprint Alerts pipeline and “Reset to defaults” on Item Types now include Issue when you have never saved a work item type list. Lists you have saved are used exactly as before.

The single-team What-if forecast assumed a two-week sprint, so teams on one-week or three-week sprints saw a scenario that disagreed with the forecast above it. What-if now uses your team’s real sprint length.

Configuration now asks before you leave the DORA Metrics, Epic, Access Control, Enterprise and Copilot tabs with unsaved changes, and before you switch project on the Enterprise tab.

The Team Health widget’s name is readable in the dark theme, and the last English text on translated views (Process Behavior metric names, the Delivery Signals trend range and two Dashboard labels) is now translated.

Version 6.58.4October 8, 2026

Forecast charts space their bars truthfully, closed forecast windows read correctly, Configuration saves clear the unsaved banner, and Aging shows each lane header once.

The Monte Carlo distribution charts left out outcomes that never occurred, so bars that were several items apart sat side by side and the confidence markers looked closer together than they are. Those outcomes now stay on the axis at 0%, so each bar sits at its true distance. This applies to the “How many?” and “When will it finish?” charts and to the mini charts on the all-teams view. Only the spacing changed: the numbers, percentiles and exports are the same.

On the forecast scorecard, a forecast whose window had passed but could not be scored yet still said “window open until” that date. It now says “window closed” with the date, followed by “not scored yet: no sprint data covers this window”. Window dates also showed a day early for viewers west of UTC and now show the correct day.

In Configuration, after you pressed Save the “You have unsaved changes” banner stayed, the button never showed “Saved”, and leaving the tab still asked whether to discard changes. Save now clears the banner and shows “Saved” on every tab. This had affected Configuration since 6.57.0.

The Aging chart showed the “Ready To Test” lane header twice when your workflow has a waiting state with that name. Each lane header now appears once. Only the label changed: which items sit in each lane and the numbers are the same. This had affected the Aging chart since 6.52.0.

Version 6.58.3October 8, 2026

Sprints with no dates read clearly on the Dashboard, the export notice is calmer, and “View all release notes” opens this page.

In a new Azure DevOps project the first sprints have no start or end date. The Dashboard’s Sprint Burnup card read “Day NaN of NaN” for such a sprint and the Current Sprint card showed “? – ?”. Sprint Burnup now shows the same “has no dates yet” message as Cumulative Flow, with the steps to set the dates in Azure DevOps Boards → Iterations, and the Current Sprint card reads “No dates set yet”. Sprints that have dates look exactly as before.

When Export Sprint CSV has nothing to export, “There is nothing to export yet…” now appears in a grey notice instead of the red error box. A real failure still shows in red.

“View all release notes” in What’s New and in Help & Support opened our blog. It now opens this release notes page. The What’s New pop-up appears once for 6.58.3 and covers 6.58.0 to 6.58.3.

Version 6.58.2October 7, 2026

Export Sprint CSV works for teams whose sprints have no dates, and for teams with no sprints.

The Dashboard’s “Export Sprint CSV” button failed with an error for a team whose recent sprints have no dates, and for a team with no sprints at all, such as a Kanban team. Sprints without dates are now left out of the export.

A team with nothing to export sees “There is nothing to export yet…” with the step to set sprint dates in Boards → Iterations, in all six languages. A real failure now shows plain-English wording instead of an Azure DevOps error code. Teams whose sprints all have dates see no change.

Version 6.58.1October 6, 2026

Cumulative Flow handles sprints with no dates, and Issues are counted on the default Basic process.

A sprint with no start or end date is the default in a brand-new Azure DevOps project. For some viewers, Cumulative Flow stopped with an error on such a sprint instead of loading. It now shows “Sprint 1 has no dates yet” (with your sprint’s name) and the two steps to set the dates in Azure DevOps. Sprints that have dates are unchanged.

In a new project on Azure DevOps’ default Basic process, WIP read 0, forecasts read “0 or more” and no completed items appeared, because Basic’s backlog type, Issue, was not counted until Item Types were saved. When nothing is saved and the project’s backlog is made of Issues, Issue now counts as Planned Work and the “These figures count…” note names it. Saved Item Types are honoured exactly as before, and Agile, Scrum and CMMI projects are unchanged.

Version 6.58.0October 5, 2026

Generated pipelines handle unusual team and project names safely, plus smaller privacy and setup improvements.

The pipeline files the extension generates (WIP monitor, delivery digest, Exec report digest, sprint alerts, performance precompute) placed team, project and organisation names into the script as quoted text, which cannot be made safe for every possible name. They now write those names in an encoded form that is decoded when the pipeline runs, so a name is only ever read as text. Pipelines generated before this release keep their old text until you generate them again; nothing breaks if you do not.

The configuration export no longer includes the Teams and Slack webhook URLs saved in WIP and sprint-alert team scopes; enter them again after an import. GitHub Copilot setup guidance now recommends a read-only token (classic read:org, or fine-grained read-only Copilot permissions) instead of manage_billing:copilot, which can also add or remove paid seats. Tokens you have already saved are not changed.

In Configuration → Scheduled Reports, you’ll now see recipient addresses on your subscriptions partly hidden (for example j•••@acme.com). Reports are still delivered to the full address. Help checks a documentation link stored for your organisation each time it reads the link, not only when it is saved.

About once per session the hub confirms which Azure DevOps organisation it is running in. It uses the short-lived token Azure DevOps issues to the signed-in user, for that one check only, and it asks for no new Azure DevOps permission. Configuration, Privacy and Data & Privacy explain this.

Version 6.57.2October 5, 2026

Flow efficiency now counts every state the same way on every view, and dashboard tiles stay calm when there is nothing to show.

Flow efficiency on Flow Metrics and Delivery Signals now treats a state that is not in your Workflow Mapping the same way the Flow Efficiency view and the Dashboard already did. A state whose name sounds like active work, such as “Code Review”, counts as active. Any other unmapped state, and a done state an item passed through before it was reopened, counts as waiting. Before, those days were added to the step before, usually In Progress, which could make flow efficiency read 100%. For teams with unmapped states the number goes down to match the Flow Efficiency view. Mapping those states in Configuration → Workflow Mapping gives the most accurate result. The stage breakdown is unchanged.

Dashboard tiles: when a team has no sprints yet, Cycle Time, Throughput, Sprint Forecast, Team Health and DORA show “No data” in grey instead of the red used for errors. At its smallest size the Team Health tile no longer shows a scrollbar: it keeps the score, grade and summary, and the WIP note stays on the score’s tooltip.

When a dashboard tile cannot load for a reason we cannot identify, the error report now includes the technical error type and the HTTP status code, so we can fix it faster. It never includes the error message, names, or any of your work-item data.

Version 6.57.0October 2, 2026

Every view now shares one header, one filter toolbar and one empty state, with larger small text and a faster first load.

Every view starts with the same header: the title, a one-line description, and a single help “?” where one exists. Filters sit in one strip directly under it, with the actions (Run, Refresh, Snapshot, Export) on the right. Views that had no title (Sprint Capacity, Next Sprint Planning, AI Metrics, the AI Improvement panel) now have one.

Small text is larger. Labels, captions and pills that were 9 to 11px are now at least 12px, buttons and pills are at least 24px tall, and page titles, section headings and card labels follow one scale. Chart axis ticks stay as they were.

The hub’s first render downloads about 120 KB less, because the release-notes text now loads only when you open What’s New or Help. While a view loads for the first time, you see an outline of the page instead of “Loading…”, and hovering a menu item starts loading that view early.

When a view has nothing to show, it says so in one line with one action, instead of zeros or a red verdict. Flow Metrics, Delivery Signals and the Retro Snapshot show a dash for commitment reliability and carryover when nothing was committed to a sprint, and Delivery Signals leaves those two cards out when no sprint in the window had a commitment.

Multi-Team Aging has one scope picker (All, Active, Selected) with the other options under “Advanced”, and a “?” that explains the Risk score. Your saved scope is unchanged.

Monte Carlo shows one card when all four confidence levels land on the same date. The Sprint Capacity view labels an ended sprint “ended” instead of marking it current.

Chart labels no longer overlap: the Cycle Time date axis thins out when crowded, close percentile labels are spread apart, and Monte Carlo shows “85% · 70%” as one label when two levels share a bucket. Exec Report sparklines show their first and last values.

Colours mean one thing. A suspicious flow efficiency is amber with a caution pill, never green; Process Behavior shows one caution instead of two; Feature Analytics cards have no decorative coloured borders.

On the AI Metrics and AI Improvement views, sample cards carry a SAMPLE stamp, use placeholder names (“Sample user A”), and header counts read “Sample: 4 alerts”.

On a narrow window (under about 1000px), the sidebar collapses by itself and comes back when the window is wider; your own collapse choice is kept as it was.

Customize shows “Saved ✓” after a change. The note about which work item types are counted is now a quiet one-line footnote with the same wording. The Dashboard’s WIP card is a normal-sized card.

Configuration: each form sits in its own card with its Save button; leaving a tab with unsaved edits asks first; Workflow Mapping shows one project at a time, expanded where states are unmapped, with one “How mapping works” note.

Version 6.56.1October 1, 2026

Clearer empty sprints, one colour scheme for forecast confidence, working Snapshot downloads, and lighter dashboard tiles.

Monte Carlo shows the four confidence levels (95%, 85%, 70% and 50%) in one set of blue shades, darker for more certain. This applies on the “How many?” and “When will it finish?” tabs and on the Dashboard’s “How many?” Forecast, and the Sprint Forecast dashboard tile now uses blue instead of purple. Before, the same level could be green on one tab and red on the other.

When a sprint has no items yet, the Dashboard’s sprint card says so instead of showing rows of zeros. A sprint whose end date has passed shows “ended” and the date in its title, and sprint lists no longer call it “active”. Live Stats shows “No items” instead of a verdict, and Cumulative Flow shows “No items in this window”. Where nothing was committed to a sprint, Sprint Velocity, Delivery Signals, Flow Metrics and Retro Snapshot show a dash instead of a red 0%.

Averages of commitment reliability and carryover now leave out sprints where nothing was committed. Before, such a sprint counted as 0% and pulled the average down. For teams that had one, the Sprint Velocity average, the Delivery Signals and Flow Metrics reliability figures, and the Team Health score go up to reflect the sprints that had a commitment. Numbers for each sprint are unchanged.

The Snapshot buttons on Cycle Time and Monte Carlo now download the chart as a picture. Before, they did nothing inside Azure DevOps.

Dashboard tiles now download about a third less before they appear, and tiles for viewers in other languages fetch far less text. The Cycle Time tile shows the latest sprint with finished work and names it, instead of 0.0 days for a sprint with nothing finished. The Team Health and Sprint Forecast tiles show all their text in your language, and the tile settings panel is readable in dark mode.

Confirmation dialogs for actions you can’t undo now start on Cancel. Keyboard focus is easier to see. Settings fields in Configuration have names for screen readers. In dark mode, checkboxes and scroll bars match the theme. The Dashboard no longer scrolls sideways, and several badges are easier to read.

Buttons no longer start with emoji, and “Ask Henry ↗” shows that it opens our website. Customize explains the difference between “Restore classic layout” and “Reset to default”. Sprint Velocity’s bar column is labelled “Relative throughput”. The Configuration notice about detected work item types appears in your language.

Version 6.55.3September 30, 2026

A quiet maintenance release. Nothing changes inside the product.

The Marketplace listing name now ends “Sprint Forecasting, Flow Metrics & Dashboards for Azure DevOps”, and its overview is shorter and opens with four short recordings of the product: the Dashboard, a Monte Carlo forecast, the Aging chart and Cycle Time. The What’s New pop-up stays at 6.55.0.

Version 6.55.2September 25, 2026

Clearer German, Spanish, French, Italian and Portuguese wording in the 6.55 screens.

The new forecast, SLE, Little’s Law and Aging text was reviewed again and wording that read too literally was fixed. The Spanish Aging explanation said “days in progress” where it means days in flow, and the German one had a grammar slip. English is unchanged.

Version 6.55.1September 25, 2026

The Aging Chart subtitle no longer repeats a stage name, and “How aging works” always shows its explanation.

When a team’s workflow mapping left one stage unconfigured, its default label could match another stage’s label, so the subtitle listed it twice (for example “Ready To Test” appearing twice). It now lists each stage name once.

Clicking “How aging works” with no items in a tracked state changed the button to “Hide explanation” but showed no text. The explanation now appears in both states.

Version 6.55.0September 25, 2026

Forecasts add up each team’s delivery and use each sprint’s real length, and Flow Metrics shows Little’s Law as a rough check.

When you forecast several teams together in the Monte Carlo view, the forecast now adds up what each team delivers, so totals are higher and reflect teams working in parallel. The result shows how many sprints and teams it draws on, for example “4–6 sprints · 3 teams”, and the ? button beside it explains how the teams are combined. A team with no finished sprints yet is left out and named. The What-if Scenario uses the same method, and the same forecast run twice gives the same result. A one-time note explains the change until you select “Got it”.

Forecasts now measure each team’s sprint length in calendar days, from the start of one sprint to the start of the next, so a two-week sprint counts as 14 days. This applies to the “How many?” and “When will it finish?” forecasts for one team or several, the All Teams cards, and the Dashboard’s “How many?” Forecast and 30-Day Forecast tiles. Expect somewhat fewer items by a given date and somewhat later finish dates.

Service Level Expectation results now count finished items that went from New straight to a later state without an active state. Their start is the first time they left New. Where this applies, the result says “Includes N items with an estimated start”, and the SLE Violations table marks each such item “estimated start”, with a tooltip you can reach from the keyboard.

On Flow Metrics, the Little’s Law panel is now “Little’s Law estimate (rough check)”. It sets an estimated average cycle time, worked out from average WIP and throughput per day over each sprint’s real calendar length, next to the actual average cycle time of the items finished in the same sprints. Sprints with no work in progress at mid-sprint are left out. The earlier cycle time floor and trend reading are no longer shown.

The “How aging works” explainer on the Aging view and the Aging & Blocked entry in How These Metrics Work now describe exactly how age is counted.

Version 6.54.2September 24, 2026

The lock screen shows where the licence key goes, and the main buttons are on the first screen.

Admins see the licence key box open straight away, under “Buy with a card”. It used to sit behind an “Already have a licence key?” link.

For people who are not admins, “Email this message” and “Copy message” now sit above the message preview. They are told to send the key to an Azure DevOps organisation admin, who pastes it on this screen. Licensed organisations see no change.

Version 6.54.1September 24, 2026

The lock screen says who can buy, and no red error box appears when a trial simply ends.

The screen and the ready-made message now say that anyone in the company can buy a licence on the website and an admin enters the key once, in all six languages.

The red “No active license is stored” box now shows only when a licence key really fails to activate. The message reads like an email, with its subject, and “Email this message” is the main button. Usage and prices sit together in one panel with a “Compare plans” link. Licensed organisations see no change.

Version 6.54.0September 23, 2026

When a trial ends, anyone on the team can pass a ready-made message to the person who buys.

Only an Azure DevOps organisation admin can activate a licence, so anyone else who opened Agile Analytics after a trial ended met two greyed-out buttons and a note to “ask an admin”. The screen now gives them a ready-made message for their admin or manager, with the pricing and invoice links in it, to copy or open in their own email. Nothing is sent from our side.

Admins see “Buy with a card” next to “Request an invoice or quote”. Where the trial saw real use, the screen shows a rounded count of the people and sessions during the trial (for example “25+ people”) and the plan prices; small numbers are never shown and no names are involved. The screen says Agile Analytics is paused and that all settings and saved data are still there. Licensed organisations see no change.

Version 6.53.1September 22, 2026

The Throughput and Sprint Forecast dashboard tiles load for teams with a long sprint history.

On a team with a long sprint history, the Throughput and Sprint Forecast dashboard tiles could give up before their data arrived and show a "could not load this tile's data" notice on every dashboard visit, while the same numbers opened fine in the hub. Each tile was loading the full sprint report behind Flow Metrics, including commitment reliability and scope churn the tiles never display, inside a dashboard tile's short time budget. The tiles now load only the throughput per sprint they show. The figures are unchanged: the same sprints, the same work items and the same definition of completed as Flow Metrics and the Monte Carlo view.

A tile that is still loading after twenty seconds now says so instead of going quiet, and waits up to a minute before showing the notice, so a large team's first load reads as progress rather than a hang.

Version 6.53.0September 16, 2026

A storage blip no longer locks a licensed organisation out, and the forecast tile explains itself before your first sprint.

When the hub opens, it reads your licence and settings from Azure DevOps extension storage. Very occasionally that storage answers a read with nothing, the same answer it gives when a document does not exist, and until now that could make a licensed organisation look unlicensed for a minute: the hub would ask our licensing service for trial state, be told the trial had ended long ago, and show the lock screen until a refresh read the stored licence again. The hub now asks Azure DevOps a second way before believing a blank answer, keeps its current state and retries when the answer cannot be confirmed, and remembers the last successful licence check in your browser for up to seven days so a licensed organisation opens as licensed even during that retry. Nothing new is sent to us: the browser copy holds what the Help page already shows and never the activation token.

The same blank answer used to be read as "the administrator email was never captured", so it was captured again on every open, and as "no trial start date", which could stamp a new one over the real date. Both now wait for a confirmed read.

A team with no completed sprints has no throughput history to forecast from. The Sprint Forecast dashboard tile and the Monte Carlo view used to treat that as an error; they now show a short line saying forecasts start after your first completed sprint.

Version 6.52.1September 16, 2026

Members always keep at least one view.

In Configuration, Access Control, User View Permissions, unticking the last remaining view used to leave members with the default set of views instead of none, the opposite of what you had just set. The last ticked view now stays on, greyed out with a short note, until you tick another one. No stored settings are altered, and organisations that never edited the grid see no difference.

Version 6.52.0September 14, 2026

Waiting states count as waiting, a view that cannot load tells you what to do, a licensing blip no longer locks anyone out, and the Privacy tab says exactly what leaves your tenant.

Until now a view that could not load its data showed you the raw text Azure DevOps returned, which for most people meant a code such as TF400813 with no hint of what to do. Every analytics view, every Configuration tab and every dashboard tile now shows one consistent notice: a short headline that says what went wrong (for example that your account cannot read this team’s work items, that the project or team is no longer available, or that Azure DevOps could not be reached), one line on what you can do about it, and the original technical detail kept behind a small “Technical details” link for anyone who needs it. Messages that were already written for a specific situation, such as a licence or seat state or a form that could not be saved because its settings could not be read, are unchanged. Nothing new is collected: the same failure reports reach us as before, with the same content.

The failed-load headlines and their advice are now shown in the language you picked for the interface (English, German, Spanish, French, Italian or Portuguese) instead of always in English.

PNG chart exports, the Retro Snapshot and Sprint Report share text, and the printable Executive Report now end with “Agile Analytics for Azure DevOps · ado-analytics.baytekdev.com” in a quiet footer. It is static text only: nothing is tracked and nothing is sent anywhere. CSV, JSON and YAML exports are exactly as before, so nothing you import into a spreadsheet changes.

If your workflow mapping has a Waiting bucket, or a team uses a Blocked state, that time used to be folded into whichever stage came just before it, so it counted as active work. It now counts as wait time everywhere: flow efficiency on Flow Metrics and Delivery Signals can read lower for those teams, and the new figure is the corrected one; the stage breakdown, the Cumulative Flow Diagram and the Aging tab show a dedicated Waiting lane; the Cumulative Flow CSV export gains a Waiting column at the end, after the existing columns, so existing imports keep their column positions. If you have never used a Waiting or Blocked state, nothing changes for you.

If your organisation’s access is managed by your plan and our licensing service is briefly unreachable, the hub remembers the access decision from the last time it checked in and keeps using it, instead of falling back to an out-of-date local list that could leave people out. It only ever replays a decision the service already made, never grants anything new, and stops applying after 7 days without contact, the same window your licence status already uses.

Configuration, Privacy now scopes its “never collect” list to usage telemetry and names the two things outside usage telemetry that do reach us: the administrator sign-in name captured on first hub open (with its undo window) and scheduled report subscriptions. It also says that events carry your organisation ID and an anonymous user ID (your Azure DevOps user GUID, used to count active users and apply seat limits), which was already true and already in the published privacy policy.

Captions, labels and other secondary text are slightly darker so they read clearly in the light theme, and locked navigation items use a proper muted colour instead of fading the whole row. Dates on Sprint Summary and Sprint Detail follow the same format as the rest of the hub and the Azure DevOps page around it. The group seat rules section says plainly that group seat rules are a Team and Business plan feature; group sync itself is unchanged.

Version 6.50.1September 8, 2026

Every view shows the numbers you asked for, your saved team comes back on every load, and a bad moment at Azure DevOps can no longer cost you your settings.

Your saved team comes back on every load again. If the project you had saved as your default was not the project the Azure DevOps page was opened from, the hub could restore the project but leave the team picker on “Select team” on every load and every refresh, so you had to pick your team again each time. The hub now waits for the saved project’s own team list before deciding, and re-applying your saved team no longer writes the same value back to your settings on every start.

Every view starts a fresh load when you change team, sprint, window or project, but the previous load was still running and whichever answer arrived last won, so clicking through teams faster than Azure DevOps answers could show one team’s throughput, cycle time, DORA figures, cumulative flow, heat map, delivery signals, process behaviour chart, executive report or investment split under another team’s name, with no error and no way to tell. All of these views now share one rule: only the load you actually asked for is allowed to draw, including its loading and error states. Org Hygiene scans the project you switched to with that project’s own teams, Sprint Detail, Retro Snapshot, the Readiness check and the add-team project picker no longer show a previous team’s data under the new name, and DORA’s CSV export buttons wait for the matching window’s figures.

Four stored documents used to answer a failed read the way they answer a brand-new install, with the built-in defaults, remember those for the session, and write them back over the real document on the next save. One hiccup could cost you your personal preferences, your notification webhooks, your work item type lists and Investment Tags, or your organisation’s access-control list, with a green “saved” message. A read that could not be completed is now never remembered, nothing is written over a document we could not read (you see “could not be loaded just now, so nothing was saved. Try again in a moment”), Configuration no longer offers to auto-detect your work item types when it could not read what you already have, access control is never bootstrapped off a failed read, and charts keep counting your custom work item types.

A sprint whose work items could not all be fetched used to come back short and be stored as the whole sprint for up to half an hour, so throughput, velocity, commitment reliability, carryover and scope change read low with nothing on screen to say so, and the failed batch fired up to two hundred more requests at a service that had just asked for fewer. A busy moment is now retried briefly with a pause; if some items still cannot be fetched, the Dashboard, Sprint Summary, Flow Metrics and Cycle Time all show the “some data could not be loaded” notice, and the short result is kept for minutes rather than half an hour. Team scoping no longer drifts for the rest of the session after one failed lookup, the project picker reads every project rather than the first hundred, and the first screen on a large project no longer waits on twenty-five sequential fetches.

Team Benchmarks shows a dash, not a bold green “0/0”, for a team the WIP Monitor has no data for, sorts such teams to the bottom of that column, and explains itself when the WIP Monitor has never been set up. Team Health’s WIP-control score no longer drops to zero for a utilisation number with a decimal. Delivery Signals’ Median Cycle Time, the Sprint Breakdown table, the trend lines under all four cards and the CSV export leave a sprint with nothing completed out instead of counting it as 0.0 days. The Cycle Time chart’s month labels and the Retro Snapshot’s sprint dates now show the calendar date the sprint used for people whose clock is set west of UTC.

Feature Analytics and Epic Analytics gather what they need first and read it in batches instead of one request per Feature, hold the result for a couple of minutes so switching away and back is instant, and have a Refresh button in the same place as the Executive Report’s. Epic Analytics reads only the Epics in your team scope. A Feature whose stories could not be read now says so instead of showing “0 stories, 0 SP, 0% complete” and is left out of the totals. Live Stats loads its teams four at a time. The hub and the dashboard tiles no longer download all six interface languages on every load: only English plus, when the interface is not in English, your language, and the screen fills in even if that language file is slow.

Dialogs take focus when they open, keep Tab inside, close on Escape and return focus afterwards. The licence-key field, the trial contact field and every other unlabelled input now has a real name, a visible focus ring appears when you tab to a control, tabs and toggle chips announce which one is selected, Org Hygiene’s sections, the heat map’s drill-down cells, Feature Analytics’ filter-clear buttons and the Live Stats team row work from the keyboard, and twelve charts that had no description for a screen reader now describe what they show. Investment Allocation’s error message is readable in light theme.

Configuration, Readiness now shows every diagnostic check, its detail and its next step in the language you picked, and AI Metrics translates its analysis (the metric glossary, benchmark and quadrant cards, recommended actions and methodology notes), not just its chrome. The AI Impact panel no longer shows an alert count built from sample data before an AI source is connected. Picking a team in a dashboard tile’s Configure panel now tells the dashboard straight away, so its Save button and preview respond the way every other Azure DevOps widget does. Sprint Capacity no longer risks mixing up two members who both have no display name.

Data & Privacy no longer describes the Sprint Assistant AI Coach or an OpenAI key setting that were removed in July, AI Metrics’ “Custom API” option is shown disabled with a plain explanation of why it cannot connect, and a custom endpoint must use HTTPS so your API key is never sent in the clear. “Export Configuration” now includes your Item Types and Investment Tags setup, so the downloaded snapshot is a complete backup of it.

Monte Carlo, DORA Metrics, WIP Monitor, Sprint Capacity, Next Sprint Planning, Retro Snapshot, Cycle Time Heatmap, Flow Efficiency, Org Hygiene, the dashboard widgets and the AI Metrics connection now tell us when they fail to load, the same way other views already did, so a broken view is caught sooner. This collects no new data: only that something failed and roughly why, never your project or work item content, and when a view crashes the error text itself is no longer sent, only a coarse category.

Version 6.49.2September 4, 2026

Your Investment Tags now reach every team, and nothing writes over them by accident.

If your organisation had set up Investment Tags and a team also had its own Item Types settings, that team never saw the tags. On Sprint Summary its exploration-tagged work stayed in the row its work item type gave it instead of moving to Exploration, so the Exploration figure read low with nothing on screen to say why. Tag lists are organisation-wide settings, edited in one place, so every team now reads your organisation’s lists, while a team’s own item type lists keep working exactly as they did. Sprint Summary figures can move for those teams, and the new figure is the corrected one. Investment Allocation was never affected: it always read the organisation’s lists.

If you had set up Investment Tags but left your work item types at the built-in defaults, opening Configuration offered to detect the types your process uses and asked you to press Save. The suggested draft did not carry your tag lists, so saving it dropped them, and the page still reported that your item type mapping had been saved. The suggestion now keeps your tag lists, so accepting it no longer costs you the tags. If you never set up tag lists, nothing about your stored settings changes.

On the Item Types tab, choosing a second team briefly showed the previous team’s lists under the new team’s name, and Save stayed available while that was on screen, so a quick click could give a team an item type list nobody chose for it. Save now waits until that team’s own lists have loaded, which is what the team picker beside it already did.

When a team had its own Item Types settings, only some views used them. Sprint Summary and Live Stats counted that team by its own work item types, while Cycle Time, the cycle time heat map, Sprint Burndown and Next Sprint Planning counted it by the project’s, and where a view only counts the types it recognises, work of a type only the team’s own settings named was left out of those views altogether. All of them now read the team’s own settings, and the note above each view naming the types being counted says so correctly. Figures can move on those views, and only for teams that have their own Item Types settings. The Team Members view still reads the project settings, because it adds several teams together and one item can belong to more than one of them.

Version 6.49.1September 3, 2026

Flow Efficiency and the service-level tables now measure a reopened item the same way every other view does.

Flow Efficiency stopped its clock at the first time an item reached done, so an item that was closed, reopened and closed again showed only its last stretch of work: one story read 1.2 days there and 10.2 days on Cycle Time, the heat map and the Exec Report. It now measures from the first start to the final close, like every other view, and the time an item sat closed before someone reopened it counts as waiting, not as work. The same measurement feeds the dashboard flow-efficiency figure and the Service Level Expectation tables, so those can move for teams with reopened items; an item that is currently reopened and not yet closed again is not measured until it is, which is what Cycle Time already did.

On Flow Metrics, the throughput distribution counted the sprint in progress as a finished sample, so a team whose last three sprints delivered 6, 7 and 5 items saw an average of 6.0 above a histogram claiming 4.5 and "high variance". The histogram now uses the same finished sprints as the headline.

When your organisation limits deployment frequency to selected pipelines and none of them ran in the project you are looking at, DORA Metrics now says so and points to the setting, instead of claiming that every pipeline in the project counts automatically.

Investment Allocation described the maintenance rule with a fixed list of tags. Since 6.49.0 that list is yours to edit, so the description now points to Configuration, Item Types, Investment tags instead of naming tags that may no longer apply.

The Sprint Detail widget showed "0d" for cycle time in a sprint with nothing completed yet. It now shows the same no-data marker as its other empty figures.

Azure DevOps could show its "taking longer than expected to load" banner over a hub that had already loaded, because the hub reported success only after its main code had downloaded and drawn. It now reports success as soon as it starts and shows its own brief loading state while the rest arrives.

Version 6.49.0September 2, 2026

Tell the hub which tags mean maintenance and which mean exploration, and it counts them your way.

Investment Allocation counted only a fixed list of maintenance tags (tech-debt, techdebt, maintenance, refactor, refactoring, chore and debt), so a team that tags its maintenance work any other way saw 0% maintenance no matter how much of it they did. Under Configuration, Item Types, an admin can now edit that list: add your own tags, remove ones you do not use. The rule stays the same: a whole tag matched exactly, upper or lower case, never a partial word. Nothing changes until you edit the list; the built-in tags keep working as before.

The same place has a second list, Exploration tags, which starts empty. Add one or more tags there, for example the tag you already put on investigation or spike work, and Investment Allocation gains an Exploration share next to Features, Bugs and Maintenance. Sprint Summary counts those items as Exploration too, whatever their work item type. Every item lands in exactly one bucket: a maintenance tag wins over an exploration tag, and the editor will not let the same tag sit in both lists.

These tag lists apply to Investment Allocation and Sprint Summary in this release. Cycle Time buckets, Sprint Burndown and Next Sprint Planning still group work by item type only, so if you use exploration tags, their Exploration figures can differ from Sprint Summary’s until those views follow the same lists.

Saving your Item Types mapping, or reverting a team back to the project mapping, during a brief connection problem could write a settings document that was missing every other project’s and team’s mapping. The hub now refuses to save when it could not read the current settings, tells you nothing was saved, and lets you try again. This is the same protection 6.48.4 added for your other settings.

Version 6.48.4August 30, 2026

A brief connection problem can no longer replace your saved settings with defaults.

A temporary problem reading your settings could quietly cost you them. When Azure DevOps briefly failed to return your saved settings, the hub treated that the same as never having any, showed the built-in defaults, and the next automatic save (for example, remembering the team you had open) wrote those defaults over your real settings. The same could happen to your organisation’s workflow mapping, which auto-discovery would then rebuild from scratch. The hub now tells the two apart: when it could not read a document, it keeps working from a temporary stand-in, never saves over the real one, and reads again a short while later.

If you press Save during such a moment, the hub says so plainly, in your language, so you know nothing was lost and can try again. Nothing changes the rest of the time: settings load, save and refresh exactly as before.

Views that depend on your workflow mapping no longer remember a failed read for the whole session. Before, one failed read kept them on the built-in mapping until you closed the tab; now the next view asks again.

The protection does not depend on Azure DevOps reporting the failure. When a read comes back empty, the hub now asks the store to create the document only if it truly does not exist, and the store refuses when it does. So even a failure that arrives looking like an empty document cannot lead to yours being replaced.

When your workflow mapping cannot be loaded for a moment, the views that depend on it now say so instead of quietly showing figures computed from the built-in defaults.

When Azure DevOps answers a settings read with nothing at all, the hub now double-checks directly with Azure DevOps before concluding that nothing was saved. If your settings are there, they are used; if the connection really is down, the hub says so and waits, rather than starting from defaults.

A workflow mapping that could not be read is no longer mistaken for one that was never set up. Before, a brief connection problem could replace every analytics view with a setup screen asking you to configure a mapping you already have. Now the views stay, a short notice says the mapping could not be checked, and the setup check and readiness report say the same instead of asking you to add one.

Version 6.48.0August 29, 2026

Refresh now asks Azure DevOps again, instead of redrawing.

Refresh really refreshes. On the Executive Report and on Sprint Summary, the button redrew the figures the hub already held, so pressing it after moving work on your board produced the same page. Both now drop those held figures first and ask Azure DevOps for current ones. Sprint Summary also reloads its teams a few at a time rather than all at once, so a board with many teams puts less load on your organisation than it did before, even while fetching more.

The WIP Monitor footer stopped claiming something it could not know. It read "Last updated" and jumped to the current time whenever you opened the view, even when every number was served from figures already held and nothing was fetched at all. The time itself has always meant "when this view was put together", so the label now reads "Snapshot" and says that plainly.

The Help page and the first-run sample card now follow your language. If you use Agile Analytics in Spanish, Portuguese, Italian, German or French, both were still answering in English throughout. Nothing changes if you use the hub in English.

The GitHub Copilot setup note names the right kind of token. It asked for a fine-grained token with permissions that only exist on a classic one, so an admin who followed it built a token that could not work and got no explanation. It now says classic, matching what the connection error already told you.

Version 6.47.5August 29, 2026

The hub now speaks your language in three places it was still answering in English.

Three messages in the hub were still English for everyone. If you use Agile Analytics in Spanish, Portuguese, Italian, German or French, three places kept answering in English: the prompt asking you to pick a team, the message shown while the hub checks your setup, and the one shown while a view loads. The team prompt is the one you would have met most often, because it appears on every view that needs a team until you choose one. All three now follow the language you have selected. Nothing changes if you use the hub in English.

Version 6.47.4August 29, 2026

Changing the team at the top of the hub now moves every view with it.

The team selector at the top of the hub now moves every view. Cumulative Flow, Cycle Time, Cycle Time Heat Map, Monte Carlo Forecasting, Process Behavior and Flow Metrics each carry their own team dropdown, and each one held on to its earlier selection when you changed team at the top. The chart stayed on the previous team while the heading named the new one, which is the harder direction to notice. Changing team at the top now updates these views, and choosing a different team inside a view still stands until the next change at the top.

The setup checklist counts only your own project’s workflow mapping. When the project you were viewing had no mapping saved, the checklist used the first mapping in the organisation and reported the project as configured. The views that rely on a mapping were meanwhile leaving unmapped states out of their figures, with nothing on screen to explain the gap. A project with no mapping of its own is now shown as needing one, and the unmapped-states note no longer lists states belonging to a different project.

Refresh on the Executive Report fetches again. The button redrew the report from figures already held for the current sprint and trend window, so pressing it after a board change produced the same page. It now clears those held figures first, which means Refresh asks Azure DevOps for the current numbers.

Version 6.47.3August 29, 2026

Three numbers that were quietly wrong, or quietly missing, now tell the truth.

The “How many?” forecast no longer answers when it cannot. With no completed sprint history there is nothing to forecast from, but the card still filled in every percentile with a zero, so a new team was shown four confident rows of “0 items or more”. That reads as a real and very bad prediction rather than an absent one. The card now says there is not enough sprint history yet, the same wording the throughput trend already used in the same situation.

CSV exports name your project. The Export Sprint CSV button on the dashboard, and the Team Benchmarks export, both wrote the internal Azure DevOps project identifier into the project column, a value that appears nowhere on screen. Both now write the project name, matching the Sprint Summary export which was always correct. Nothing else about the files changed.

Version 6.47.2August 28, 2026

Two views now say what their numbers cover, instead of leaving you to work it out.

Investment Allocation explains an empty per-team breakdown. The “All teams” figure is a project-wide count, while each team row is filtered to that team’s area path. Work sitting outside every team’s areas was therefore counted once at the top and nowhere underneath, which read as a missing-data fault. The “All teams” row now states how many completed items are not in any team’s area path. Assigning those areas to a team brings the items into the breakdown.

The dashboard headline figures say what they cover. Flow Efficiency and Lead Time are drawn from the last six sprints, while Throughput and WIP describe the sprint in progress. All four sat side by side with only Throughput labelled, so a quiet sprint could show zero throughput next to a healthy efficiency figure and look self-contradictory. Each figure now carries its own period. Flow Efficiency also flags a suspicious 100% on the dashboard, the same note the Flow Metrics view already shows, because a perfect score almost always means wait time was never recorded rather than a flawless process.

Version 6.47.1August 28, 2026

Epic and Feature Analytics now explain why a view could not load, instead of always pointing at permissions.

Epic Analytics and Feature Analytics read the standard “Epic” and “Feature” work item types by name. When that query failed, both views reported the cause as an Azure DevOps permission issue, whatever the real reason was. If your process template renames or removes those types, the view now says so, instead of sending you to check an access level that is fine. Permission failures keep the same explanation as before, and a connection problem now reads as temporary.

Version 6.47.0August 27, 2026

Investment Allocation can now leave Tasks out, built for teams whose Tasks are story breakdown, not separate work.

Exclude Tasks from Investment Allocation (opt-in). Teams that split every story into child Tasks saw the view read mostly “maintenance”, because each Task counted alongside its parent story. Turn on “Exclude Tasks” next to the category picker and Tasks leave the count entirely: the features / bugs / maintenance shares, the unplanned number, story-point weighting and custom category slices all stop seeing them, and the view says “Tasks are excluded from this view” while the setting is on. The choice is per person, and nothing changes until you turn it on.

Version 6.46.1August 25, 2026

The stuck-work radar now sees carryover: an item left open in last sprint can no longer hide from Multi-Team Aging.

Multi-Team Aging watches carryover. When a team starts a new sprint, items still open in the previous sprint’s iteration used to disappear from the cross-team radar, often exactly the oldest, most stuck work. The radar now reads each team’s previous sprint too and folds its still-open items into every count, risk score and the top-stale list, labeled “(carryover)” so you can see where each item actually lives. Finished work is never carried forward.

One word per number on Sprint Capacity. The last-sprint line now says “planned 9, completed 5”: completed counts everything the team finished in the sprint, while Sprint Summary’s “delivered 4 of 9” remains the verdict against the day-one commitment. Two different questions, now two different words.

Feature Analytics says which “Done” it counts. The Done tile now reads “Done (by state)”: a feature whose stories are 100% complete but whose own state is still New or Active is deliberately not counted done, and the label now says so.

Org Hygiene says when it could not look. If an iteration cannot be checked, for example when its team is missing a team field or area configuration, the empty-iteration section now says how many were skipped instead of silently treating them as fine. An unreadable team is itself a hygiene smell, and now it is visible.

Version 6.45.1August 23, 2026

A tightened measurement engine: one strict rulebook for reliability, time to start, flow efficiency and cycle time, applied the same way on every view.

Commitment reliability, tightened. It now grades against the items committed at the end of the sprint’s first day and delivered by sprint end, with a 24-hour grace for items closed the morning after review. Work that lands in a later sprint counts as carryover rather than delivery, and cancelled items count for neither side. The day-one baseline is now reconstructed for every viewer, so organisations whose history was imported from another tool are fully supported for the first time. Because the bar is stricter, the number may read lower than before; it is the same number on Sprint Summary, Delivery Signals, the leadership report and the retro snapshot, and How These Metrics Work spells out the exact rule.

Time to Start, now measured. The Delivery Signals card previously showed a placeholder. It now measures the days from sprint start (or the item’s creation, if later) until work actually began, shows the median per sprint, and says plainly when there is nothing measurable yet.

One definition of flow efficiency. Every view now follows the industry-standard definition, hands-on time divided by the time from first work to done. Time an item waited before anyone started it no longer counts against you, so percentages will typically rise; a note flags a suspicious 100% when no waiting states are mapped, on every view that shows the number.

Forecasts and averages agree with each other. The sprint still in progress no longer weighs on velocity averages and Monte Carlo forecasts as if it were a finished sprint. Its row stays visible; it just no longer tilts the aggregate, so mid-sprint forecasts may read slightly higher. Brand-new teams now see a real early trend from their first sprint instead of a flat zero.

Cycle time holds one anchor. Reopened items are measured from the first time work started, on every view, so an item that bounced back picks up its full story. Those items will read longer, and more truthfully. History reads that hit Azure DevOps rate limits are now retried, and if history still cannot be read completely, the Cycle Time view and dashboard say the ages are approximate, the same disclosure Aging and Cumulative Flow already made.

Sprint Summary team cards, redesigned. Each card now leads with the number a coach presents: delivered versus committed, as a single large figure with a delivery bar, carry-over and moved-to-next-sprint counts, and progress bars for planned work, bugs and exploration. Colour now only appears when it means something, scope change highlights only past your configured churn threshold, and empty buckets say “none planned” instead of pretending to be complete.

Clearer labels everywhere. Commitment copy now says day one, a team with no active sprint in Azure DevOps sees “(latest)” and a hint instead of “(Current)”, Aging says “no history yet” instead of a zero-day threshold, the Cumulative Flow scope-added count includes items created mid-sprint, DORA’s empty state distinguishes “no successful runs” from “no runs”, the weekend setting says it applies to Aging only, and How These Metrics Work documents every rule above, including a new Time to Start entry.

Version 6.44.0August 23, 2026

Metrics grade on your definitions: set your own thresholds, weight by story points, and see how every number is calculated.

Grade on your own thresholds. The six Delivery Signals cutoffs (throughput, carry-over, cycle time, time to start, flow efficiency and blocked items) can now be set for your whole organisation from Configuration. The built-in defaults are exactly what the view used before, so nothing changes until an admin edits them, and a reset button puts the defaults back.

Story points where they matter. Investment Allocation gains a Count / Story Points toggle (count stays the default, your choice is remembered per person, and items without an estimate are counted as zero with a note saying how many). Epic Analytics adds “story points completed” as a progress basis, and both the epic and feature views now carry a short note explaining exactly how progress is calculated, including that delivery forecasts always count stories, whichever basis you pick.

Grades you can defend. DORA deployment frequency no longer awards an Elite or High band while it is counting every pipeline run (the deploys-per-week number stays), and a one-click link takes you to the setting where you choose which pipelines are deployments. Monte Carlo forecasts now say plainly when they are built on fewer than four sprints of history, so a preliminary range is never mistaken for a confident one.

Locked settings show the organisation’s value. When your organisation locks a setting, everyone now sees the value the organisation actually enforces instead of their own older choice, and unlocking brings each person’s own setting back untouched.

Admin quality of life. Pending access requests can be selected together and approved in bulk as User (admin approvals stay one by one, deliberately). Every CSV export from any view is now recorded in the admin activity log, the log tells you when entries could not be recorded, and two admins editing access control at the same time no longer overwrite each other silently.

A friendlier first run, and small polish everywhere. New teammates get a short, skippable four-step tour of the navigation. The leadership report adds small trend lines for throughput and reliability. Aging & Blocked links straight to the multi-team view, Sprint Summary loads large team lists more smoothly, and an epic with no child items now reports progress from its own state instead of sitting at zero.

Version 6.43.0August 18, 2026

Set your organisation’s defaults in one place, override them project by project, and lock the settings that must not change.

Organisation defaults, set once. A new Enterprise tab in Configuration sets the starting point for the settings each person otherwise configures alone: dashboard thresholds, WIP Monitor display settings, count or points, weekend handling, chart controls, the teams a new person watches, and the work item types your charts count. People already using Agile Analytics keep their own settings, and nothing changes for them until you choose to apply something to everyone. When you do, the confirmation lists the values you are about to publish rather than only the name of the setting, so you can see that you are setting a reliability target of 87 rather than simply “dashboard thresholds”. Anyone whose setting is replaced can put their own back in one click.

Per-project overrides and locks. Override the organisation baseline for an individual project directly from that project’s settings, which helps when one team genuinely needs its own thresholds or item types. Blank fields keep following the organisation baseline for that project, including when the baseline changes later, so you only need to set what is actually different. Lock a setting to stop it being overridden by any individual project: a locked setting follows the organisation baseline everywhere until you unlock it. This is an operational control rather than a security boundary, because Azure DevOps organisation storage can be written by any member of your organisation.

See when a change lands, and keep a record of it. Settings are picked up the next time each person opens Agile Analytics, so the Enterprise tab shows who has picked up the current version by name, alongside a total count and when the most recent person did. Every admin change to access, seats, settings, workflow mapping, report subscriptions and privacy is recorded in an activity log, which you can export as CSV. Only a user id and a time are recorded for a pick-up, the log and the export stay inside your own Azure DevOps organisation, and neither is ever sent to us.

Your WIP Monitor settings now shape the dashboard. “Teams shown at once” limits the board to the teams that matter most, with a note showing how many are hidden. If you watch more than 8 teams and have never changed this setting, the board will now show the top 8 by your chosen sort with a “Showing 8 of 12” note until you raise the limit, up to 24. “Sort teams by” reorders the board: risk puts over-limit and near-limit teams first, and alphabetical and utilization work as named. “Threshold mode” moves the near-limit warning: conservative warns at 70% of a team’s WIP limit, standard at 80%, aggressive at 90%. You can also link the monitor pipeline you set up to each team card for one-click access.

Cycle time and flow metrics now follow each project’s own workflow. Workflow mapping is detected for each project you open rather than assumed from the first one you configured. If your organisation works across several projects, the figures for projects beyond your first are now measured against their own workflow, so those numbers may change. Where they change, they are more accurate than they were before.

Flow Efficiency and wait time are corrected. A state that had once been routed through Review left a hidden residue behind even after it was remapped, and that residue was still counted as waiting time. It inflated wait time and pushed Flow Efficiency down. The residue is now cleared. If your organisation was carrying any, Flow Efficiency will rise and cycle time and wait time will fall the next time you open those views. Nothing has changed in how your team works and there is nothing for you to do: these are the true figures.

User Metrics shows your people, and views say what they need. The query behind User Metrics was being rejected by Azure DevOps on every load without reporting it, so the view rendered but only ever showed an “Unassigned” row. That is fixed, and your named contributors now appear. A dashboard widget added without a team used to show “Loading...” indefinitely and now asks you to select a team. Applying a setting to everyone is reflected straight away in the admin’s own session without a reload, and saving a baseline now says plainly that people already using Agile Analytics are unaffected until you apply it to everyone. Saving one Configuration tab no longer quietly saves unsaved edits made on another.

Scheduled reports, and smaller fixes throughout. Deleting a scheduled report subscription now requires administrator access, matching creating one and replacing its delivery secret, so anyone with a seat who could previously delete a report will now need an administrator to do it. Pausing a report stays available to everyone with a seat. Number fields no longer silently rewrite what you type: a value outside the allowed range is corrected when you leave the field, and the range is shown beside it. Service level expectation targets are validated the same way. Copy to clipboard and webhook buttons now work reliably inside Azure DevOps, and many labels that were still appearing in English are now translated across all six supported languages.

Version 6.42.5

Override your organisation’s defaults project by project, and let your WIP Monitor settings shape the whole dashboard.

Per-project overrides and locks. Override the organisation baseline for an individual project directly from that project’s settings, useful when one team genuinely needs its own thresholds or item types. Blank fields follow the organisation baseline for that project, including when the baseline changes later, so you only need to set what is actually different. Lock a setting to stop it being overridden by any individual project: a locked setting follows the organisation baseline in every project until you unlock it.

Your WIP Monitor settings now shape the dashboard. “Teams shown at once” limits the board to the teams that matter most, with a note showing how many are hidden. Organisations already watching more than 8 teams will see the top 8 by their chosen sort plus a “Showing 8 of 12” note until the limit is raised, up to 24. “Sort teams by” reorders the board: risk puts over-limit and near-limit teams first, and alphabetical and utilization work as named. “Threshold mode” moves the near-limit warning: conservative warns at 70% of a team’s WIP limit, standard at 80%, aggressive at 90%. You can also link the monitor pipeline you set up to each team card for one-click access.

Cycle time and flow metrics now understand each project’s own workflow automatically. Workflow mapping is now detected for each project you open rather than assumed from the first one you configured, so if your organisation works across several projects, numbers for the projects beyond your first may become more accurate now that they are measured against their own workflow.

Scheduled report subscriptions are now fully admin-managed. Deleting a report subscription now requires administrator access too, matching creating one and replacing its delivery secret. Pausing a report stays available to everyone with a seat.

Quality and safety fixes. The confirm button in dialogs shows as the primary action again. Two admins working at the same time no longer overwrite each other’s access-control or per-project changes. Error messages are clearer when the licensing service can’t be reached, and in AI Metrics posting guidance. Dark theme: dialogs and the redesigned interface now render with proper contrast throughout.

Version 6.42.0

Set your organisation’s starting point for the settings everyone otherwise configures alone, and see when it lands.

Organisation defaults. A new Enterprise tab in Configuration sets the starting point for dashboard thresholds, WIP Monitor display settings, units, weekend handling, chart controls, the teams a new person watches, and the work item types your charts count. People already using Agile Analytics keep their own settings and nothing changes for them until you choose to apply something to everyone.

Apply to everyone now shows what it will do. Ticking a setting and confirming used to show only the name of the setting. The confirmation now lists the values you are about to publish, so you can see that you are setting a reliability target of 87 rather than simply "dashboard thresholds". Anyone whose setting is replaced can put their own back in one click.

Applying WIP Monitor settings no longer clears team setup. Publishing the WIP display settings replaced each person’s watched teams, their per team limits, their Slack or Teams channel and their background monitor. It now changes only the display settings the option describes and leaves everything else exactly as each person set it.

You can see when a push lands. Settings are picked up the next time each person opens Agile Analytics, so there was no way to tell whether a change had reached anyone. The Enterprise tab now shows who has picked up the current version by name, alongside a total count and when the most recent person did. Only a user id and a time are recorded, they stay in your own Azure DevOps organisation, and they are never sent to us.

Version 6.41.6

Give a whole team access at once, and keep a record of every admin change in your own organisation.

Seats by group. Assign seats to an Azure DevOps group instead of person by person. Membership is read in the admin’s own browser and stays in your organisation, and the list is brought back into step when an admin opens Agile Analytics. If a group cannot be read, nothing is changed at all rather than acting on a partial answer, and the summary says which group was skipped and why.

Admin activity log. Changes to access, seats, workflow mapping, report subscriptions and privacy are now recorded with who made them and when. The log lives in your own organisation’s storage and is never sent to us.

Workflow mapping covers every project. Mapping was previously discovered for one project only, so teams working across several projects saw gaps. It now covers each project you open, and discovery running for two projects at once can no longer overwrite one project’s mapping with another’s.

Report subscriptions are now admin-only. Creating a scheduled report, and replacing its delivery secret, now require administrator access, matching how the rest of access control already works.

Version 6.41.5August 12, 2026

Scheduled reports tell you when setup is unfinished, and a lost secret is no longer a dead end.

Setting up a scheduled report now lists every step. Delivery runs from a pipeline in your own project, and that pipeline needs a variable named REPORT_RELAY_SECRET holding the secret shown when you create the report. That step used to appear only inside the downloaded pipeline file, so a report could look finished and never send anything. The panel now walks through all four steps in order.

A report that has never been delivered now says so. Because delivery is driven from your own pipeline, an unfinished setup produces no error anywhere: the report simply never arrives. Once a full delivery cycle has passed with nothing sent, the report says its setup is unfinished and points at the pipeline variable to check, rather than showing "Not delivered yet" indefinitely.

A lost secret can be replaced. The relay secret is shown once when a report is created, and there was previously no way to see it again: if the setup was interrupted, the only route forward was deleting the report and starting over. You can now generate a replacement from the report itself, which reopens the same setup steps. A report already delivering will pause until you update the variable in your pipeline, so the confirmation says so before anything changes.

Version 6.41.2August 10, 2026

Epic landing forecasts show a range, not a single promise.

Epic Analytics now shows a landing range for epics forecast to land within a year: the most likely date and a date the epic’s own delivery history supports with 85% confidence. Epics landing further out already expressed their landing as a quarter range; near-term epics, the ones teams commit to in front of stakeholders, showed a single date, which reads as a promise no forecast can keep. Hover the range to see how many completed items it rests on.

The range is resampled from the epic’s own completed stories over your recent forecast window, the same simulation behind the beyond-a-year quarter estimates, so a forecast drifting past the one-year mark reads as the same estimate getting coarser, not a different feature. When the likely date lands within the year but the 85% date does not, the row says so instead of naming a date it cannot support.

When an epic’s recent history is too thin to carry a range (fewer than five completed stories, or completions concentrated into fewer than three recent weeks), the row keeps the single pace-based date it has always shown. Teams on three-week sprints now qualify: closing work at sprint end lands in exactly three recent weeks, which previously was not enough for the beyond-a-year quarter estimate either, so some far-out epics will show a quarter range where they showed nothing before. And when Azure DevOps returns only part of an epic’s data, Epic Analytics now says the numbers may be incomplete instead of quietly showing lower ones.

Version 6.40.0August 4, 2026

Your sprint burnup reads true, and more of the product speaks your language.

Sprint Burnup: the Ideal line now runs from zero to your full sprint scope across the sprint, which is the standard burnup convention. Before, it paced only the work committed on day one, so if your team took on more work mid-sprint, the Ideal line sat below your Scope line and a team that had delivered everything could still read as behind.

Aging lane labels now work when you have renamed your workflow states. The short labels on the Multi-Team Aging cards were matched against the default state names, so if your team calls its states something else, those labels did not appear. They now follow your states whatever you have called them.

More of the product follows your language. Around ninety further labels are now translated across all six languages: the Retro Snapshot image export (which stayed English even when the card beside it was translated), dashboard widget names in the Customize panel, the item-type scope notes, the feature quarter table, team benchmark columns, and a number of error messages. Two smaller fixes for anyone not working in English: the access-request button now correctly reads “Access requested” after you request access, and the quarter table’s first column aligns correctly in every language.

Version 6.38.0August 2, 2026

Seats you assign, and numbers you can trust.

Team and Business plans now manage access with assigned seats. Your extension admin assigns people in Configuration → Access Control; assigned users, admins included, each hold one seat, and seats can be swapped at any time. When every seat is taken the next assignment is simply refused until you free one or upgrade, so you can never be billed for more than your plan and nobody who holds a seat is ever cut off.

Colleagues without a seat are not locked out of the product: they see the Dashboard, every other view stays visible in the navigation, and Access Control names your admin so requesting a seat is one click. Premium plans and trials have no seats to manage: everyone is in, and the server now confirms that on every load so a stored setting can never lock a licensed team out.

Accuracy improvements across the analytics: time-in-stage and flow efficiency stop the clock when an item is completed instead of running to the end of the sprint, commitment is measured at the end of every sprint’s first day for every team alike, and SLE breach status always agrees with the numbers displayed. Several figures will read lower than before; they are now the true ones.

Version 6.37.0August 1, 2026

Trials are open to your whole organisation, with nothing to set up.

Everyone in your Azure DevOps organisation now has full access for the length of your trial. There is nothing to configure and nobody to add: the whole team can open every view from the first day, so the people who will actually use the reports are the ones evaluating them. Previously a trial started with access limited to the person who set the extension up, and everyone else reached a reduced set of pages.

Any access settings you had already chosen are kept exactly as you left them. Nothing is rewritten in your organisation, so if you restricted access to named people during a trial, that configuration is still there and takes effect if you move to a Team or Business plan. Access management applies only on those plans.

Configuration → Access Control is unchanged in behaviour and now records anonymous usage counts, in line with the configuration telemetry already described in the privacy policy. No names, email addresses or user identifiers are collected, and the existing opt-out at Configuration → Privacy continues to apply.

Version 6.36.2July 31, 2026

Median cycle time is corrected, and five pages explain themselves instead of showing nothing.

Cycle time percentiles are corrected and will read lower. The calculation selected one position too high in the sorted list whenever the percentile landed exactly on a whole item, which for a median is every even number of completed items. A team with two finished items of 2 and 100 days saw a median of 100 days, the slower of the two. The correction affects the Dashboard headline figure, the Cycle Time view, the Coach panel, the per-type breakdown and the Flow Metrics histogram, and every value now matches a cycle time an item actually had. The Aging chart judges item age against these percentiles, so its amber and red thresholds shift with them and fewer items will be marked at risk. Teams with an odd number of completed items are unaffected: those figures were already correct. Small teams saw the largest distortion.

Five pages no longer render an empty area when no team is selected. WIP Monitor, Process Behavior, Cycle Time Heat Map, Feature Analytics and Audit Trail each need a team, but the prompt asking for one was not shown, leaving a blank content area with nothing to click. This was reachable whenever the list of teams could not be loaded. Each page now shows the same "Pick a team in the sidebar" message the other team-based pages already showed.

A subscription payment that fails now says so in the product, and your access continues while it is retried. Previously nothing in the extension mentioned it. The notice appears for organisation administrators with a route to resolve it; everyone else is pointed to their administrator rather than shown an action they cannot take.

Configuration → Reports no longer offers to create the schedule pipeline for you. The button required permissions this extension does not request, so it could only ever fail, and its error message asked for a reinstall that could not help. Downloading the pipeline file and adding it to your Azure DevOps project, the method described in the documentation, is unchanged and is now the only one offered.

Version 6.36.0

Each team counts its own work, and long-range forecasts say how sure they are.

Work item types can now be set for a single team as well as for the whole project. Teams in one organisation do not always share a vocabulary: a type that represents a deliverable increment for one team is the unit of to-do work beneath a deliverable for another, and one project-wide selection had to suit both. Configuration → Item Types now offers a scope selector. A team without its own selection continues to follow the project default exactly as before, and nothing needs to be reconfigured.

Epic landing forecasts continue past twelve months. Beyond that point a precise date is not defensible, so the estimate previously stopped: the roadmap showed nothing and the list said “12+ months at pace”. Epic Analytics now gives a most-likely quarter alongside the quarter by which delivery is 85% likely, calculated by resampling the epic’s own recent delivery. Where an epic has too little completed work to support that calculation, it still says so rather than estimating.

Flow Efficiency now counts queue states as waiting time. States such as “Ready to Test” or “Awaiting Review” sit in the Test and Review stages of your workflow mapping and were previously counted as active work, which made cycle time look almost entirely productive and pushed the efficiency figure close to 100%. Those states are queues and are now measured as such. Your flow efficiency figure will fall and your wait time will rise: that is the measurement being corrected, not a change in how your team is working. Your workflow mapping does not need to change; the stages themselves are unaffected on every other view.

The Throughput Distribution chart stays readable when its markers fall close together. The average, p50 and p85 labels could overlap the variance summary above them, and the last column label could run into the axis caption. The chart now reserves room for each.

Version 6.35.0

Sprint history includes the work that moved on.

Aging Trend by Sprint now reads each past sprint’s contents as they stood when that sprint ended. Previously the chart asked Azure DevOps what a sprint contains today. Moving a work item to a later sprint rewrites its iteration, so anything carried forward disappeared from the sprint it actually aged in, and the longer a piece of work ran, the more likely it had been moved. Historical figures may therefore be higher than before: that is work becoming visible, not new delay.

The current sprint is unchanged, and so is every other view. Sprint Summary, commitment and scope figures read the same point in time they always have.

Where your Azure DevOps access does not permit a historical lookup, the chart still renders using the sprint’s current contents rather than showing an error.

Version 6.34.8July 27, 2026

Charts keep their history, and say what they are counting.

Aging Trend by Sprint reads each past sprint as it stood at the time. Previously every sprint was judged by where its items are today, so closed items dropped out of the lanes and a finished sprint’s averages fell towards zero as the team carried on working: the better a team’s hygiene, the emptier its history looked. Each past sprint is now reconstructed from the item’s recorded transitions, so items count towards the sprint they actually aged in and later progress no longer rewrites what has already happened. The current sprint is unchanged.

The Cumulative Flow Diagram no longer omits items without change history. Where Azure DevOps returns no revisions for a work item (common on older process templates, and possible for any organisation when a request does not complete), that item was previously counted in no band on any day. Those items are now placed correctly.

Each dashboard states the work item types it counts. Sprint-based figures are filtered by the Item Types configuration, and until now nothing outside the Configuration screen said so. Every affected view now names the types behind its numbers and points to where that setting lives.

Charts disclose incomplete history rather than estimating in silence. When Azure DevOps does not return an item’s change history, the Aging and Cumulative Flow views now say how many items are affected and that their time in each stage is estimated. Those items are still counted.

Configuration no longer offers a work item type list that the metrics do not read. The General tab presented work item type checkboxes that had no effect wherever an Item Types mapping exists. The heading remains and now points to the setting that applies; the metrics themselves are unchanged.

GitHub Copilot connection failures name the actual problem. Azure DevOps returns the same response whether an organisation cannot be seen with your token or simply has no Copilot Metrics access. The connection test now distinguishes the two and says which one to fix, in all six supported languages.

Version 6.34.6

Ask Henry now opens our own support form.

Ask Henry moved off Google Forms. The button now opens a form on our website with the same questions, and submissions go directly to Baytek rather than through a third-party form provider. When opened from the extension, the form carries your organisation name and extension version so you do not need to retype them; both are used only to answer your message, as described in the privacy policy.

Version 6.34.5July 26, 2026

Change failure rate is now measured from real deployments.

Change failure rate from real deployments. DORA Metrics now reports "N of M sampled deploys failed", calculated from pipeline runs and their linked work items. A deployment is counted as failed only when a bug was opened within its responsibility window and a later deployment shipped that bug's fix; deployments that cannot be attributed with confidence are disclosed on the card rather than counted. The existing defect-based estimate remains unchanged and is now labelled as a proxy. This uses the deploy-linked setting introduced in 6.33: no new settings, permissions, or additional Azure DevOps calls are required.

Clearer error messages. When Azure DevOps declines a work-item read because of the access level, the message now explains that Stakeholder access cannot read analytics data and that the Basic access level is required, including what to request from your organisation administrator. GitHub Copilot connection errors (expired token, missing scope, organisation not found, rate limit) are now localised in all six supported languages.

Data & Privacy transparency. The page now lists the data sent to Baytek (the organisation ID used for licence validation, and usage and error telemetry) and the data that stays in your tenant: work-item content, project and team names, user names and email addresses. Usage telemetry can be disabled under Configuration → Privacy. The page links to the published privacy policy and terms.

Service status page. Live health for the website, checkout, licence activation and telemetry ingestion is published at ado-analytics.baytekdev.com/status, including an incident history.

Fixes. Sprint totals on the Dashboard throughput chart now render at full contrast in both themes.

Version 6.33.1July 21, 2026

A tidier SLE Violations table.

The SLE Violations table could render a cycle time with its full floating-point tail (e.g. "16.000011574074072") whenever an item's close time was not an exact day multiple. The column now rounds to one decimal, matching the "Over by" column.

Version 6.33.0July 21, 2026

Lead time measured from your real deployments, opt-in, shown beside the numbers you already trust.

Deploy-linked lead time (opt-in). DORA Metrics can now measure lead time to the moment a successful pipeline run shipped each item, using the work items Azure DevOps already links to every run (AB# commit mentions and linked pull requests). Enable it under Configuration → DORA Metrics; it appears beside the existing work-item measure and never replaces it. The card always discloses its basis (how many completed items had a linked deploy and how many recent runs were sampled), with a weekly trend line. A pipeline picker lets you say which pipelines are deployments (default: all), and a one-click "Open settings" takes you there from the DORA view.

Know when you're behind. If the version you're running is two or more releases behind the Marketplace, a slim dismissable notice says so. Azure DevOps usually updates extensions when you reopen them; if the notice keeps returning, an organization admin may need to approve the update under Organization settings → Extensions.

Next Sprint Planning, one click from the Dashboard. A small card beside Sprint Velocity now links to the view that answers "what should we commit to next sprint?". It was easy to miss in the navigation.

SLE Violations grew up. Cards order worst-first, a summary strip counts violations at a glance, an all-quiet board collapses into one guided panel instead of a wall of empty sections, and you can widen the window to 3, 6, or 12 sprints. Every "No data" row now explains in plain words what that target counts and points you to the setting that adjusts it.

Clearer grades and pickers. A DORA "Low" badge now explains which cutoff was crossed and what the next level takes: a measurement, not a verdict. Field pickers across configuration list your organisation's own fields first, with the Azure DevOps built-ins below.

Fixed: team selection survives a hard refresh. A browser refresh (especially Ctrl+Shift+R) could restore your project but come back with no team selected. The saved team now restores reliably, with a sensible fallback when it no longer exists.

Version 6.32.2July 20, 2026

The SLE match editor now catches a setup that measures something different from what you meant.

On an SLE named after a category value (like "Spike"), selecting only work-item types under "Customize what counts" silently meant "count every item of those types", when the natural reading is that the selection combines with the row’s name. The editor now says so in plain words the moment that setup exists, and offers the correction as one click: "Add ‘Spike’ as a Category value."

Version 6.32.1July 20, 2026

Slice Investment Allocation by your own fields, drill into SLE violations, and several numbers got honest.

Investment Allocation gains a "Break down by" picker: group completed work by any field (e.g. Category), rename or merge its values into named buckets on the view, and "(not set)" items always stay visible. The default buckets are unchanged.

A new SLE Violations page lists, for every Service Level Expectation, the completed items that exceeded its window, worst first, with cycle days and a link to each item. Every SLE also states in plain words what it counts, with an optional "Customize what counts" editor for exact work-item types and category values.

Commitment reliability and carryover now measure against a start-of-sprint snapshot with a done-by-sprint-end check. Teams that roll unfinished work forward were reading 100% reliability and ~0% carryover for every past sprint. Scope added/removed are now real counts and churn uses one definition everywhere. Past sprints’ figures shift once to the true values; that shift is the fix landing, not a change in your delivery.

The DORA Deployment Frequency badge grades on real thresholds instead of always reading "High"; the detail-metric sample draws from a larger pool for large organisations; and the velocity trend on the Exec Report and Retro Snapshot computes from your actual history instead of always reading flat.

The "Work category field" picker (Configuration → SLEs) listed number-type fields and hid the text and picklist fields it exists for. The field you actually want now appears, and structural noise (Area/Iteration Level, meeting-attendee fields) is filtered out.

Sprints whose items were backfilled after the fact (for example history migrated from Jira or a CSV file) have no start-of-sprint snapshot to measure against; they now fall back to the current-membership computation instead of reading a flat 0% reliability.

Version 6.31.1July 18, 2026

Service Level Expectations now find work you categorize with a field or a tag, not just by work-item type.

Service Level Expectations now match by category field or tag when nothing matches by type. An SLE reads "X% of <name> finish in Y days" and matched <name> only against the Azure DevOps work-item type. Teams that track a category another way (a Spike that is really a User Story whose custom "Category" field is set to "Spike", or a story tagged "Spike") saw "No data" on that target even when the work existed and had breached the window.

Point the tool at your category field once. Configuration → SLEs now has a "Work category field" picker listing your organisation's text fields. Choose the field that sub-categorizes your work and every SLE target whose name is not a work-item type matches that field's value instead (exact, case-insensitive). It is org-wide: one admin sets it and the whole team's Dashboard agrees. Teams that categorize with tags need no setup at all: a target name is matched against item tags automatically.

Fallback-only, by design. An SLE whose name already matches a real work-item type keeps its exact previous behaviour, so no SLE that was already reporting a number changes. And because SLEs always evaluate the trailing sprint window (they are not "started" when you save), your past sprints count immediately. If a "No data" SLE starts showing results after this update, that is the work it was always meant to measure, not new activity.

Version 6.31.0July 17, 2026

See throughput and WIP in story points, not just item counts, and DORA numbers get more representative for large orgs.

See throughput and WIP in story points. Flow Metrics and the WIP Monitor now carry a Count / Points toggle. In Points mode, Flow Metrics shows throughput as points per sprint across the trend, histogram, and sprint table, and the WIP Monitor shows each team’s in-progress load in points. Points come from your existing estimates (Story Points, a numeric Size/Effort field, or a T-shirt size from XS to XXL), so there is nothing new to configure. The default stays Count, so nothing changes unless you switch, and your choice is remembered per view.

A missing estimate never reads as zero. Items without an estimate are excluded from the Points total, and the view tells you how many were left out ("N of M items have no estimate, excluded from the Points view"). WIP limits, the "how many will we finish?" forecast, and CSV exports stay item-based by design: points are a display choice on the throughput and load views, not a change to those calculations.

More representative DORA numbers for large organisations. For an organisation with more than 200 completed items in a window, the DORA detail metrics (lead time for changes, time to restore) were sampling the 200 OLDEST items rather than a representative spread. They now draw a genuine random sample across the window. If your organisation is past that size, your lead-time and restore-time figures may shift after this update; the new numbers are the more representative ones, not a change in your delivery. Separately, imported items that were "born done" with no recorded completion date now carry a small "estimated date" note in the Cycle Time views, so a derived date is never shown as an exact one.

Version 6.30.1July 16, 2026

Workflow Mapping now tells you when it can’t read your states, instead of failing silently.

Workflow Mapping now explains a states-not-found account instead of failing silently. Auto-discovery reads your Azure DevOps project’s work-item states to suggest mapping options. When it can’t (most often because the account has a Stakeholder access level or lacks permission to read the project’s process, or because the project simply has no custom states yet), the tab now shows a short notice next to the mapping controls explaining why, and confirms you can still map your states manually below. No change if your states load normally.

Version 6.30.0July 16, 2026

Your “how many will we finish?” forecast was reading backwards and is now fixed, and every chart got a clearer redesign.

Your delivery forecast was reading backwards. The “How many items will we finish?” cards pair a confidence level with a number, but the two were inverted: the 95%-confidence row showed the 95th-percentile outcome (a number you’d reach only about 5% of the time) while the 50% row showed an easy target. Higher confidence now correctly maps to a lower, safer commitment: “95% = we’ll almost certainly finish at least this many.” If you use these figures for sprint commitments, expect them to change with this update; the new numbers are the honest ones.

A clearer look across every chart. Flow Efficiency now shows the healthy 15–40% band as a gauge with your team’s marker on it, states a plain verdict, and flags a suspicious near-100% score as likely missing wait data, so a data gap no longer looks like a perfect process. WIP Monitor replaces its wall of team cards with a sorted load chart where the busiest team and anyone over their limit float to the top, each bar showing how close a team is to its WIP limit. The Flow Trend chart no longer squeezes throughput and cycle-time days onto one shared axis (which made the two lines misleading to compare); each measure now has its own panel. Delivery Signals collapses its duplicated metric rows into one card per signal. Live Stats, Aging & Blocked, Cycle Time, DORA, Cumulative Flow, Process Behaviour and the rest all get the same consistent palette and denser, more scannable layouts. These are visual changes; the underlying numbers are unchanged.

Two views read more truthfully. The Cycle Time Heat Map’s rows were inverted, putting the slowest band on top; the fastest delivery times now read at the top. And Aging & Blocked tints an item’s risk by how long it has been flowing against your cycle-time percentiles, rather than by time in a single stage, so where an item’s colour shifts, that is the more accurate read, not new movement.

Version 6.29.0July 15, 2026

Truer numbers for imported work and unmapped workflows, and the whole product now speaks all six languages.

Imported work now tells the truth. Items migrated into Azure DevOps already completed, the shape Jira and CSV imports produce, took their completion time from the import moment instead of the real close date. That inflated cycle times into the hundreds of days while SLE and burnup claimed nothing was finished. These items now use their recorded completion dates, so affected charts will correct themselves once. That is the fix landing, not new movement.

One consistent answer to "is this done?". For teams without a saved workflow mapping, items in Resolved, Completed, or Ready for Release read as eternally in progress in some views (aging forever, missing from Cycle Time) while other views counted them delivered. All views now agree these states are done. If Resolved means "awaiting verification" for your team, your Workflow Mapping remains the boss: set it there and every chart follows. States named like "Ready to Accept" are now recognised as the review stage they are.

Honest confidence labels, everywhere numbers travel. Different views graded the same sample size differently: one said Medium where another said Low. One ruler now applies across the product, so a small sample reads as Low consistently (same numbers, a more honest label), and low-sample caveats follow your figures into the report digest, exec summary, and retro views.

The whole product in your language, plus small fixes. Dashboard widgets, Team Benchmarks (including its bottleneck findings and recommendations) and the settings around them now render in all six supported languages. Blocked time is now counted for non-English blocked states (it was silently zero). The single-item timeline no longer accrues phantom "sitting in Done" days for Ready-for-Release or non-English done states, and duplicating a browser tab now lands on the view you were on instead of resetting to the Dashboard.

Version 6.28.1July 13, 2026

Cycle time and flow metrics improved, and your license stays put through network blips.

Improved cycle time and flow metrics. We refined how these metrics handle week and day boundaries, counting each day in your team’s own time zone rather than a fixed reference. Your numbers now line up more closely with what actually happened; existing charts may shift slightly where the old boundary handling was off; that is the refinement, not new data.

Steadier license access. A temporary network or server interruption could briefly show the trial-ended lock screen to an organisation with a valid license. Access now holds through short-lived interruptions, and the screen no longer flashes the app in before it settles.

Reliable scheduled report digests. A scheduled digest could quietly fail to send or arrive empty. Digests now generate and deliver as configured.

A smoother start for new teams. New organisations get a short Getting Started checklist pointing to the reports teams find most useful first, and first-time installs are no longer greeted with a “What’s New” note meant for returning users. Trial admins also get a clearer path to purchase, alongside a set of smaller reliability and polish fixes.

Version 6.28.0July 10, 2026

Sprint Alerts now installs, and stops announcing changes that happened weeks ago.

Sprint Alerts, fixed twice. The pipeline file we generated was not valid YAML, so Azure DevOps would not accept it. If you tried to set Sprint Alerts up and it was rejected, that is the reason. Separately, Azure DevOps stamps each entry in an item’s change history with the date of the change that FOLLOWED it, so an ordinary edit could make an item announce "Entered Done" for a close that happened a month earlier, and genuine alerts carried a far-future placeholder date. Every state change is now judged by its own recorded moment. Because the fixes live in the generated file, an already-installed pipeline keeps running the old one: download it again from Configuration → Sprint Alerts and replace it.

Delivery Impact, in AI Metrics. Connect GitHub Copilot or M365 Copilot and see whether your higher-adoption teams show a worse change-failure rate than your lower-adoption ones: the pattern the DORA research warns about, measured on your own teams rather than an industry average. You get a scatter of adoption score against change-failure rate, a high-versus-low cohort comparison, and a per-team table flagging where AI velocity may be outrunning quality, over a 14, 30, or 90-day window. Work-item content stays in your Azure DevOps tenant.

A weekly Delivery Digest, and a gentler first hour. Pick a team, a channel, and a day in Configuration → Communications, download the pipeline, and add it to your own project: it runs on a schedule inside your tenant using the pipeline’s own access token, with no personal access token, and work-item content stays in your Azure DevOps tenant. New installs also get a short Getting Started checklist, and organisations returning after a long break get a brief welcome-back note; established teams see neither. Everything here is available in all six supported languages, and the pipeline files we generate now handle team and project names containing apostrophes, quotes, or spaces correctly.

Version 6.27.1July 2026

A closed item no longer shows as active, and completion dates are now exact.

What you may have seen: an item long closed in Azure DevOps still listed as active, with its time-in-state still counting, and adding a comment or editing any field made it snap to completed.

The cause, plainly: Azure DevOps stamps each entry in an item’s change history with the date of the change that FOLLOWED it, and marks the newest entry with a far-future placeholder. We took those dates at face value, so a close that was the item’s final change had no usable date and was silently dropped, and a close followed by an unrelated edit was dated at that later edit. Every state change is now dated by its own recorded moment.

What changes in your numbers: closed items show as closed right away with the true completion date, and items that had later edits lose the artificial extra days, so some cycle times and time-in-state figures shorten. Nothing else moves: no settings, mappings, or stored data are affected, and history displays correctly as soon as this version loads.

Version 6.27.0July 2026

Every view now tells the whole truth: one Done ruler, no silent gaps, and two numbers that got more honest.

One Done ruler: views that previously judged completion by fixed state names or Azure DevOps’ closed-date field now use your Workflow Mapping. If your team finishes work in a custom state that your Workflow Mapping lists as Done (like "Accepted" or "Shipped"), Feature and Epic progress, DORA counts, Investment Allocation, the stale-backlog scan, forecast scoring, and the emailed exec digest all count it now, and they all agree with the Cycle Time views. If you use scheduled report emails, regenerate the pipeline YAML once (Configuration → Scheduled Reports) to bring the digest along.

Failed data is never presented as real: a team whose data could not load is excluded from Team Benchmarks and named, so it can no longer rank as a healthy, fastest team on empty numbers. Org Hygiene reports how many teams were actually scanned, Multi-Team Aging and Feature Analytics name anything they could not load, and Monte Carlo says when it forecast from fewer sprints than requested.

The Cycle Time transparency from 6.26.2 now covers the Heat Map, Aging & Blocked (items in unmapped states are counted instead of vanishing, including blocked ones), and Live Stats (a per-team marker when unmapped states are deflating the Done %).

WIP history (metric change): only items with a real work-start signal count as historical work-in-progress. Backlog items parked in an iteration no longer inflate the trend, so it now measures the same thing as the live WIP tile. If your WIP-history line steps down after this update, that is the more accurate reading.

Flow efficiency (metric change): items that spent their entire cycle waiting (genuine 0% flow efficiency) now count toward the average instead of being skipped. Wait-heavy teams may see the number drop; that is the honest signal this metric exists to give.

Smaller truths: the Epic landing forecast no longer mixes units when progress is measured in Features; capacity math in Next Sprint Planning no longer double-counts a personal day that overlaps a team day off; "All Teams" in User Metrics says "12 of N" when capped; and DORA / Investment Allocation say so plainly if a team’s numbers had to fall back to project-wide scope.

Version 6.26.2July 2026

Cycle Time that explains itself: nothing hidden, nothing overstated.

Left-out work is now visible: when stories that look finished are not counted, a notice on the Cycle Time view lists how many were excluded and the exact reason (a state not mapped as Done, a work item type not mapped to a chart bucket, or unusable dates), with a shortcut to the Workflow Mapping.

Estimated starts are labelled: 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 now render with a dashed outline, carry an "estimated start" legend entry, 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. This update is about the chart telling you what it is (and is not) showing.

Version 6.26.1July 2026

DORA metrics, exec reports on a schedule, and a clear view of where the work goes.

Exec Report (new view): a print-ready delivery-health summary built for the "how are we doing?" question. Print to PDF straight from the view.

Scheduled report emails: deliver that report automatically: weekly, monthly, daily, or at sprint end. Recipients confirm by email before anything is sent, every email carries one-click unsubscribe, and report content is never stored on our servers.

DORA Metrics (new view): the four industry-standard delivery metrics (deployment frequency, lead time for changes, change failure rate, time to restore), computed from your work items and pipelines, inside Azure DevOps.

Investment Allocation (new view): the share of completed work going to features vs. bugs vs. maintenance, per team, with unplanned work called out. Anything the view can’t classify is shown explicitly, never silently dropped.

One-time permission prompt: after this update, Azure DevOps will ask you to re-approve the extension once. That’s the new read-only Pipelines permission that powers the DORA deployment metrics. It’s the only change to what the extension can access.

Version 6.25.3June 27, 2026

Clearer throughput, stronger accessibility, and even more of the app in your language.

Throughput, redesigned: the Throughput chart now labels each sprint’s bar, draws your average as a reference line, and adds a six-sprint sparkline, so you can read the trend and spot a dip immediately. The numbers are unchanged, just easier to see.

Accessibility improvements: you can navigate the charts and the view switcher entirely by keyboard with a clear focus outline; dark-mode colour contrast was strengthened to meet WCAG AA (including banners and the trial bar); confirm dialogs and loading states are clearer; and Azure DevOps errors now read in plain language with a way forward.

More of the app in your language: the Cycle Time card’s explanation and its empty-state guidance now switch with your chosen display language (English, German, Spanish, French, Italian or Portuguese), matching the rest of the interface.

Under-the-hood polish: dashboard text now draws from the shared colour palette for consistent contrast in light and dark. Your data, layout, and settings are unchanged.

Version 6.25.0June 25, 2026

Your language, a refreshed look, and a sharper Dashboard.

Multilingual interface: choose a display language from the 🌐 menu and the navigation, every view, configuration, and dialogs switch across English, German, Spanish, French, Italian, and Portuguese. (A few deeply technical terms keep their common form.)

Visual refresh: a consistent, on-brand look across the dashboard, charts, and every view, in both light and dark themes, sharper and calmer to read. Nothing in your data or saved layout changed.

A sharper Dashboard: the default now leads with your headline KPIs, then cycle time beside the “how many?” forecast, then throughput beside WIP. Sprint Velocity, Sprint Detail, Burndown and SLE Breaches stay one click away: open Customize to show, hide, or reorder any widget, or “Restore classic layout” to bring the previous set back. Nothing was deleted, and if you had already customized your dashboard, your layout is untouched.

Version 6.24.4June 23, 2026

Drill from an Epic straight into its Features, see exactly what’s carrying, or stalling, each Epic.

Epic → Feature drill-down: every Epic in Epic Analytics now expands inline to its child Features (completion progress, completed and total stories, and story points), sorted most-complete first, each linking to Azure DevOps. Collapsed by default, so the list looks exactly as before until you open an epic.

Open any Epic in the full Feature Analytics view: an “Open in Feature Analytics →” link on each Epic takes you to the feature list, quarterly roadmap heatmaps, and SP trend scoped to that Epic.

Filter Feature Analytics by Epic: a new Epic dropdown scopes the entire Feature Analytics view (list, roadmap and KPIs) to a single Epic, with a removable chip so you can clear it in one click.

Version 6.24.2June 23, 2026

Hot fix for Feature Analytics: team scoping now works, and Removed work no longer counts against your progress.

Fixed: scoping Feature Analytics to one or more teams could show “No feature data available for this scope” even when those teams had features. Selecting a team now correctly shows that team’s features, stories, and completion.

Fixed: features and stories in a Removed state were being counted as incomplete, lowering progress and completion percentages in Epic and Feature Analytics. Removed work is now excluded from the totals, so progress reflects only active and completed work.

Version 6.24.1June 22, 2026

Industry Benchmarks is now live: opt in and your comparison appears as similar teams join.

Industry Benchmarks goes live: opting in now contributes a snapshot linked only to your organisation ID (cycle time, throughput, and sprint-completion % as rounded numbers, plus a coarse team-size bracket and Scrum/Kanban) and reads back how you compare. Until at least 5 similar teams have joined, the panel shows an honest “building your peer group” state with an illustrative preview, then your real comparison appears automatically. Turning it off deletes your contributed snapshot. Still off by default; never sends work items, names, project/team names, or your exact head-count.

Fix: support links now report the running extension version instead of a stale older version.

Version 6.24.0June 21, 2026

Industry Benchmarks: see how your delivery compares to similar teams, opt-in and linked only to your organisation ID.

Industry Benchmarks (new, opt-in, off by default): a new view under Team Benchmarks that shows how your team’s delivery compares to similar Azure DevOps teams (cycle time, throughput and sprint-completion percentage) as a distribution. If you opt in, only rounded summary numbers plus a coarse team-size bracket and methodology are ever shared, linked only to your organisation ID; never work item titles, names, project names, or your exact head-count. Comparisons are only shown for a peer group of at least 5 organisations, as rounded ranges, never another company’s individual numbers. You can turn it off at any time, and a sample comparison is shown so you can see the value before deciding.

Version 6.23.0June 21, 2026

A customizable dashboard, Team Benchmarks with bottleneck spotting, a plan-aware Epic Roadmap, and CSV export everywhere.

Customizable Dashboard: a new “Customize” button lets you drag widgets to reorder (or use the ▲▼ buttons), show or hide any widget, and switch on optional extras (throughput trend, 30-day forecast headline, cycle-time data quality). Your layout is saved to your account, teammates keep their own, and “Reset to default” restores the original any time. If you never customize, the Dashboard looks exactly as before.

Plan-aware Epic Roadmap: the Roadmap lays out Q1–Q4 with a year stepper: step back to see what shipped, forward to plan. Set an epic’s Target Date in Azure DevOps (or assign it to a quarter iteration) and it appears in that quarter, marked 📌 Planned, even before it has a completion pace; a ⚠ flags an epic whose pace forecast lands later than the plan. Epics with neither a plan nor a recent pace are listed honestly as Unscheduled, never given a made-up date.

Export to CSV everywhere, and drill into Azure DevOps: every dashboard with a table has an Export to CSV button, now including Live Stats, and each export matches exactly what’s on screen. Flow Efficiency, Aging / Blocked, Org Hygiene and the Audit Trail let you open the items behind the numbers: one item or the whole list as a query.

Epic Analytics scoping: scope Epic Analytics to a team and it shows the Epics that team is actually working on, even when your Epics live at the project root; on the Enterprise plan it can span several projects and teams at once (Configuration → Epic Analytics). The Epic list leads with your most-complete epics and expands on one click.

Team Benchmarks spots the bottleneck, not the “loser”: the cross-team view (previously “Team Leaderboard”) now opens with a plain-English read of where delivery is getting stuck: your top bottleneck team and the signal behind it (flow efficiency, WIP, carryover, cycle time vs your other teams, or commitment reliability), each with a suggested next step, while the full sortable metrics table stays right below. It measures flow, not people, and never ranks on story points.

More honest metrics: the WIP badge now reads “WIP Control” (how close you are to your limit), the Team Benchmarks CSV carries every on-screen column, and the AI inline-vs-chat split is clearly marked as an estimate.

Numbers that agree across views: the Dashboard’s cycle-time card now reads from the same source as the dedicated Cycle Time view (your last 6 sprints of completed work, measured through your workflow mapping), so the two always match. We also removed an out-of-date first-run popup that could appear on fresh installs.

Version 6.21.0June 20, 2026

More accurate, more resilient workflow auto-discovery, across every process and language.

Your workflow is mapped from the source of truth. Auto-discovery now reads your states and their Azure DevOps categories together and treats the category as authoritative, so states are bucketed correctly across Agile, Scrum, CMMI, Basic, and custom processes, in any language, even when a state has an unusual name.

It follows how your board is set up. When a state sits in a column you’ve marked as a starting, in-progress, or done column, that placement guides how the state is counted, matching the flow you actually work to.

Brief Azure DevOps hiccups no longer leave you on generic defaults. If reading your states momentarily fails we retry, and if it still can’t be read we try again next time instead of locking in a one-size-fits-all mapping. Your existing mappings are never overwritten.