What may look different after updating
This release corrects several measurements at once, so the important part first. If your team moves unfinished stories to the next sprint — which is exactly what good scrum teams do — your past sprints’ commitment reliability has been reading 100% and carryover near 0%, regardless of what actually happened. Both were computed from the sprint’s contents as they look today, after the unfinished work left. They now measure against a snapshot of what the sprint contained just after it started, and only count work completed by sprint end. Expect reliability to drop to the true figure and carryover to rise — once, everywhere, with the same number on every view. Sprints whose history was migrated into Azure DevOps after the fact (Jira or CSV imports) have no snapshot to measure against and keep the current-contents computation rather than reading a false zero. The DORA Deployment Frequency badge also stops flattering: it graded "High" for any organisation with build data and now uses real thresholds. None of these shifts mean your delivery changed — the measurements got better.
Slice Investment Allocation by the fields you actually use
Built-in Features / Bugs / Maintenance buckets are a start, but most organisations categorize work their own way. Point Investment Allocation at any field — a "Category", "Component", or custom field — and the completed-work breakdown regroups by that field’s values, per team and project-wide. Messy values can be renamed and merged into named buckets right on the view ("AWS", "aws" and "Amazon" become one "Cloud" slice), and items with no value always appear as their own "(not set)" slice — this view never silently drops work. Your setup travels with the Configuration export, and the default remains the built-in buckets.
A violations page for your Service Level Expectations
SLEs promise "85% of stories finish in 14 days." When one is missed, the next question is always which items — so there is now a page for exactly that. For every target: the completed items that exceeded the window, worst first, with cycle days, how far over, and a direct link to each item (or one click to open them all as an Azure DevOps query).
SLEs now say — and let you choose — what they count
Every SLE row in Configuration states in plain language what it matches. And where the matching used to be automatic-only, a "Customize what counts" editor now lets you target exact work-item types and category-field values, in any combination — "Bugs, plus anything whose Category is Spike." Leave it untouched and behavior is identical to before. The field picker behind this also got fixed: it was listing number-type fields while hiding the text and picklist fields it exists for, so the field you actually wanted often wasn’t offered. It is now — and structural noise is filtered out.
6.32.2: the match editor now catches a setup that says something different from what you meant
Hours after 6.32.1 went live, a customer walked into the one trap the new editor made too easy: on an SLE named "Spike", ticking only "User Story" under "Customize what counts" quietly means "count every User Story" — the name stops mattering, and the target tracks far more work than intended. The natural reading is that the checkbox combines with the name; it doesn’t. 6.32.2 warns in plain words the moment that setup exists and offers the correction as one click — Add "Spike" as a Category value. If you have already customized an SLE, reopen the editor once; it will tell you whether your setup counts what you meant it to.
Smaller corrections in the same spirit
Velocity trends on the Exec Report and Retro Snapshot now compute from your real sprint history (a placeholder had them reading flat since the feature shipped). Scope churn uses one definition everywhere — added plus removed — so Sprint Summary and Sprint Velocity finally agree. The DORA detail metrics draw their random sample from a larger pool for big organisations. And the connection heartbeat on the support page actually checks the connection now.
Updating
The update applies automatically when you reopen the extension — nothing to install. The What’s New popup shows the highlights once. If a number moved and you want to understand exactly why, ask Henry from the top bar — we reply personally within 24 hours, and we would rather explain a correction than have you distrust a chart.