Three releases, one honest catch-up
We shipped 6.28, 6.29, and 6.30 in quick succession and let the website fall behind the product — this post closes that gap. As always, we lead with what was wrong and what may look different after updating, because a chart you distrust is worse than no chart. The short version: several numbers got more truthful, one forecast got safer, and the whole product got easier to read. None of these changes mean your delivery changed — the measurements got better.
6.30: your delivery forecast was reading backwards
This is the one to read before your next sprint commitment. The Monte Carlo "How many items will we finish?" cards pair a confidence level with a number — but the two were inverted: the 95%-confidence row showed a number you would 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 will almost certainly finish at least this many." If you use these figures to commit, expect them to change; the new numbers are the honest ones. In the same spirit, the Cycle Time Heat Map had its rows inverted (slowest band on top — fastest now reads first), and Aging & Blocked tints an item’s risk by how long it has been flowing against your own cycle-time percentiles rather than time in a single stage.
6.29: truer numbers for imported work and unmapped workflows
If your organisation migrated from Jira or imported work items from CSV, you may have seen absurd cycle times — items claiming hundreds of days because completed work took its "done" date from the import moment, while burnup insisted nothing was finished. Imported items now use their real completion dates. Separately, teams without a saved Workflow Mapping had items in Resolved, Completed, or Ready for Release states reading as eternally in progress in some views while others counted them delivered; every view now gives the same answer, and your Workflow Mapping remains the boss if Resolved means "awaiting verification" for your team. Confidence labels also now use one ruler product-wide, and low-sample caveats follow your numbers into the digest, exec summary, and retro views. The full product also now renders in all six supported languages — including dashboard widgets, Team Benchmarks, and blocked-state tracking, which previously counted blocked days as zero for non-English state names.
6.28: Sprint Alerts now installs, and stops crying wolf
Two honest fixes first. The Sprint Alerts pipeline file we generated was malformed, so Azure DevOps would not accept it — if you tried to set up Sprint Alerts and it was rejected, that is why; the file is valid now. And alerts could announce a transition that happened weeks ago: Azure DevOps stamps each entry in an item’s change history with the date of the change that followed it, so editing a comment or a title could trigger "Entered Done" for a close from a month earlier. Every state change is now judged by its own recorded moment. If you already run a Sprint Alerts pipeline, download it again (Configuration → Sprint Alerts) and replace the file — an installed pipeline keeps running the old YAML until you do. 6.28 also brought Delivery Impact in AI Metrics (does higher Copilot adoption correlate with a worse change-failure rate on your teams?), a weekly Delivery Digest to Slack or Teams that runs entirely inside your tenant, and a Getting Started checklist for new installs.
6.28.1: day counts in your time zone, and a license that holds through blips
Cycle time and flow metrics now count each day in your team’s own time zone rather than a fixed reference, so numbers line up more closely with what actually happened — existing charts may shift slightly where the old boundary handling was off. A brief network interruption could also flash the "trial ended" lock screen even when the license was perfectly valid; access now holds steady through short-lived blips. And a scheduled report digest that could quietly fail to send, or arrive empty, now delivers as configured.
6.30: a clearer look across every chart
Alongside the forecast fix, 6.30 modernised the product’s charts end to end. Flow Efficiency shows the healthy 15–40% band as a gauge with your team’s marker and 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 floats to the top. Flow Trend gives each measure its own panel instead of squeezing two units onto one axis. Live Stats, Aging & Blocked, Cycle Time, DORA, Cumulative Flow, Process Behaviour and the rest share one consistent palette and denser, more scannable layouts. These are visual changes — the underlying numbers are unchanged. A small 6.30.1 follow-up also tells you plainly when workflow states could not be loaded instead of showing an empty mapping screen.
Numbers that may have moved — the recap
After updating through these releases you may notice: Monte Carlo commitment numbers changed (the confidence inversion fix — the new figures are the safe ones); cycle times dropped sharply for imported/migrated work (real completion dates); day counts shifted slightly (your own time zone); the Heat Map reads fastest-first; and wait-heavy items may tint differently in Aging & Blocked. Every one of these is a correction, not a change in your delivery.
Updating
The update applies automatically when you reopen the extension — nothing to install. The What’s New popup shows the highlights once. If you run a Sprint Alerts pipeline, remember the one manual step above: re-download the YAML so the fixes reach your installed pipeline. Questions about a number that moved? Ask Henry from the top bar — we reply personally within 24 hours, and we would genuinely rather explain a correction than have you distrust a chart.