Finished sprints keep the numbers they earned
The Aging Trend by Sprint chart was judging every past sprint by where its work items sit today. That sounds harmless until you follow it through: an item closed last month is no longer ageing anywhere, so it left the lanes entirely; an item that moved on after the sprint contributed nothing to the sprint it was actually stuck in. The result was that a finished sprint's figures drained towards zero as the team kept working — and the more diligently a team closed things out, the emptier its own history looked. 6.34.8 reconstructs each past sprint from the transitions the items actually recorded, so a sprint reports what was true at the time. Work now counts towards the sprint it aged in, and later progress no longer edits the past.
Related: Aging and blocked work
The current sprint is untouched
Only the historical rows changed. Your live sprint reads exactly as it did yesterday, and the shared calculation behind the sprint report, notification triggers and the agile-coach snapshot was deliberately left alone. If a past sprint in your Aging Trend suddenly shows real numbers where it used to show a flat line, that is the fix landing — not a new measurement.
The Cumulative Flow Diagram stops leaving work out
Azure DevOps does not always return an item's change history. It is common on older process templates, and it can happen to any organisation when a request does not complete. Where that happened, the item carried an internal placeholder that matched none of your workflow states — so the Cumulative Flow Diagram counted it in no band, on any day. Not misplaced: invisible. Those items are now placed correctly. If your CFD has looked thinner than your sprint, this is a likely reason.
Related: Flow metrics
When we cannot read the history, the chart says so
Until now, an item whose history Azure DevOps refused to return arrived looking identical to an item that had genuinely never moved — so the chart estimated its timings and said nothing about it. The Aging and Cumulative Flow views now tell you how many items are affected and that their time in each stage is estimated rather than measured. Those items are still counted; only their precision is in question. We would rather show you a chart that admits its own gaps than one that looks more certain than it is.
Every dashboard states what it is counting
Sprint-based figures have always been filtered by your Item Types configuration — which work item types count as planned work, which count as bugs, which count as exploration. Nothing outside the Configuration screen ever said so, which meant the numbers were being shaped by a setting most people never saw. Each affected view now names the types behind its figures and points to where that setting lives. Nothing about the filtering changed; it is simply visible now.
A setting that did nothing is gone
Configuration → General offered a list of work item type checkboxes that the metrics did not read. Wherever an Item Types mapping exists — which is effectively everywhere, since one is created automatically — that list had no effect at all. A customer changed it, saw no change in their forecast, and reasonably concluded the product was broken. They were right. The heading remains and now points at the setting that actually applies, and no metric changes as a result.
GitHub Copilot connection errors name the real problem
Azure DevOps returns the same response whether your token cannot see an organisation or the organisation simply has no Copilot Metrics access, so our message had to describe both — and understandably, people acted on the half they could control and retyped the organisation name. The connection test now checks which of the two it is and says so: if the name is right, it tells you the name is right and that re-entering it will not help. In all six supported languages.
Updating
The update applies automatically the next time you reopen the extension — nothing to install. If a chart shows you a different past than it did last week, that is the point of this release: the earlier version was the one that was wrong. If a number still looks unexplainable, Ask Henry from the top bar and a real person will reply within one business day.
Related: Service status