What may look different after updating
Two things, and both are deliberate. If your organisation has more than 200 completed items in a DORA window, your lead-time and restore-time percentiles may shift once — the sample behind them is now representative instead of skewed to the oldest items, so the new figures are the truer ones, not a change in your delivery. And if a Service Level Expectation that always said "No data" suddenly starts reporting after 6.31.1, that is the work it was always meant to measure finally being found. Everything else in this release is opt-in: nothing changes until you flip a switch.
Count / Points: measure delivery the way your team estimates
Some teams measure delivery in items finished; others 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, the histogram, and the sprint table, and the WIP Monitor shows each team’s in-progress load in points. Points are read from the estimates you already have — Story Points, a numeric Size or Effort field, or a T-shirt size (XS–XXL) — 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 quietly reads as zero
The obvious failure mode of a points view is silent undercounting: three unestimated bugs slip through a sprint and your "points delivered" quietly loses work. So items with no estimate are excluded from the Points total and the view says so plainly — "N of M items have no estimate" — every time. WIP limits, delivery forecasts, and CSV exports stay item-based by design: limits are set in items, and changing the forecasting model was not a risk worth bundling into a toggle.
DORA detail metrics: a representative sample, honestly disclosed
The DORA lead-time and time-to-restore views compute their percentiles from a detailed sample of completed items, capped at 200 for performance. Until now, organisations past that cap got the 200 oldest items in the window — an artefact of how the work-item query returns results, and a bias toward stale data. The sample is now drawn randomly across the whole window. If you are past that size, expect the percentiles to move once after updating; the new numbers describe your whole window instead of its oldest corner. Separately, imported work items that arrived "born done" with no recorded completion date now carry a small "estimated date" note in Cycle Time views, so a derived date is never presented as an exact one.
6.31.1: SLEs find work you categorize with a field or a tag
Service Level Expectations read "X% of this work type finishes in Y days" — and until now, "work type" meant exactly an Azure DevOps work-item type. Plenty of teams categorize differently: a Spike that is really a User Story with a custom "Category" field set to Spike, or a story carrying a "Spike" tag. Those teams configured an SLE and got "No data" forever, even while the work breached the window sprint after sprint. Two fixes: targets named after a tag now match with no setup at all, and a new "Work category field" setting (Configuration → SLEs) points SLEs at whatever field sub-categorizes your work — org-wide, so one admin sets it and every Dashboard agrees. Both are fallback-only: an SLE that already matched a real work-item type is byte-for-byte untouched. Because SLEs evaluate the trailing sprint window, your past sprints count immediately.
Updating
The update applies automatically when you reopen the extension — nothing to install. The What’s New popup shows the highlights once. If a DORA percentile or a previously-empty SLE 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.