Version 6.2.3 is focused on one thing: making the configuration model behind your metrics transparent, so the numbers on your charts match what your team actually tracks in Azure DevOps. The headline change is per-type filtering on Cycle Time — if you map two ADO types (say, Bug and Issue) into the same analytics category, you can now isolate either one and see its own percentiles. Alongside that, the three analytics categories have clearer names, every chart shows which ADO types are feeding it, and a yellow warning appears when work items have types that aren't mapped anywhere. Since 6.2.0 we've also shipped first-install auto-detection of work item types and a simpler Workflow Mapping tab.
Per-type filtering on Cycle Time
When you map more than one Azure DevOps work item type into the same analytics category — for example Bug and Issue both feeding Bugs, or User Story and Feature both feeding Planned Work — the Cycle Time chart now shows a sub-row of pills under each category. Toggle one on its own and the chart, p50, p70, p85, and p95 numbers all recalculate for just that ADO type. Defaults stay all-on, so nothing changes for existing customers unless they choose to drill in.
- One pill per ADO type that feeds the category, with live counts.
- Click a single pill to isolate that type; click again to add another back.
- Percentiles, distribution, and the items table all update together.
Clearer category names
The three analytics categories have been renamed to make it obvious that any Azure DevOps type can be mapped into them. Internal data and APIs are unchanged — this is purely a labelling pass.
- "Stories" is now "Planned Work" — covers User Story, Feature, Product Backlog Item, Requirement, or whatever your team uses for committed delivery.
- "Bug" is now "Bugs" — and accepts Bug, Defect, Issue, or any equivalent type from your process.
- "Research" is now "Exploration" — for Spikes, investigations, and time-boxed discovery work.
The Item Types tab descriptions have been rewritten to match, with concrete examples for each category so it's obvious where a given ADO type belongs.
"What's counted" banner on every chart
Cycle Time, Live Stats, and similar views now show a small banner that lists the actual ADO type names feeding each category, with a Configure item types link. Sprint Summary cards show the same information as compact pills. The goal is that anyone reading a chart can answer the question "where does this number come from?" without leaving the view.
Warning when work item types are unmapped
If items in scope have ADO types that aren't mapped into any category, a yellow warning now appears on the chart listing those types and counts — for example, "Feature (3), Spike (2) — excluded from this chart". Clicking the warning jumps straight to Configuration → Item Types so you can decide where each type should go. This closes a long-standing rough edge where items would silently drop out of metrics with no visible signal.
Auto-detect on first install
On the first Configuration tab load with default mappings, the extension now scans your Azure DevOps project for work item types and stages a suggested mapping as a draft. The admin reviews the suggestion and clicks Save to apply it. If you've already customised your mapping, auto-detect leaves it alone — it only fires when the mapping is still the unmodified default, so existing setups are never overwritten.
Workflow Mapping tab simplified
Workflow Mapping had two ways to add a custom work item type — a free-text input on the toolbar and a per-card variant — and they could disagree with the Item Type Mapping. Both inputs are gone. The dropdown of work item types is now driven directly by the Item Type Mapping, so adding a new ADO type happens in one place (Item Types tab) and flows through to Workflow Mapping automatically. A green explainer banner at the top of Workflow Mapping points to Item Types for anyone who lands here looking for the old controls.
The story behind this release
Most of these changes came out of a conversation with an agile coach who maps Bug and Issue into the same Bugs category and told us, plainly, "I can't have two different cycle times for them." The per-type pills are a direct answer: same category for the rollups, separate percentiles when you want to see how each ADO type is actually flowing. The renamed categories, the "what's counted" banner, and the unmapped-type warning all came from the same root: the configuration model was working correctly, but it wasn't visible from the charts. This release makes it visible.
What's next
A few customers have asked for more than three categories at the data level — true portfolio-level reporting where Epics, Features, and Stories each get their own analytics rollup rather than mapping into a shared bucket. We're actively scoping that work based on customer feedback and will share more as it firms up. In the meantime, if your team's structure pushes against the three-category model, drop us a note — the more concrete examples we have, the better the design will be.
Update to 6.2.3 from the Visual Studio Marketplace. Already installed? The What's New dialog will re-fire on first load after the upgrade, so the team will see what changed without anyone needing to share a link.