Why this release exists
A customer asked us a sharp question: why did some of their closed stories not appear on the Cycle Time chart, and why were some day counts higher than reality? Answering it honestly (in 6.26.2) led us to audit every view in the product for the same class of problem — places where a number renders confidently while quietly excluding, estimating, or substituting data. 6.27 is the result: the largest data-integrity release we have shipped. No new views this time; instead, every existing view now tells you the whole truth.
One definition of "done" everywhere
Some views judged completion by your Workflow Mapping while others used fixed state names or Azure DevOps’ closed-date field. For teams that finish work in a custom state — "Accepted", "Shipped", a non-English state — that meant two views could disagree about the same board. Now every view uses your Workflow Mapping — the states YOU list as Done are the single ruler: Feature and Epic progress, DORA counts, Investment Allocation, the stale-backlog scan, forecast scoring, and the emailed exec digest all count the same work as done, and they all agree with the Cycle Time views. One thing to do if you use scheduled report emails: regenerate the pipeline YAML once (Configuration → Scheduled Reports) so the emailed digest joins in.
Nothing fails silently anymore
When data cannot be loaded, the product now says so instead of blending the gap into the numbers. A team whose data failed to load is excluded from Team Benchmarks and named — previously an empty result could rank as a healthy, fastest team. Org Hygiene reports how many teams were actually scanned; Multi-Team Aging and Feature Analytics name anything they could not load; Monte Carlo tells you when it forecast from fewer sprints than you requested; and every capped list says "showing N of M". The Cycle Time transparency from 6.26.2 now also covers the Heat Map, Aging & Blocked — where items in unmapped states are counted instead of vanishing, including blocked ones — and Live Stats.
Two metrics got more truthful — and may shift
This is the part we most want you to read before you look at your charts. First, WIP history: it no longer counts backlog items that were parked in an iteration but never started, so the history trend now measures the same thing as the live WIP tile next to it. If your WIP-history line steps down after this update, that is the more accurate reading. Second, flow efficiency: items that spent their entire cycle waiting — genuine 0% flow efficiency — now count toward the average instead of being skipped. Wait-heavy teams may see the number drop; that is the honest signal this metric exists to give. Neither change means your delivery changed. The measurements got better.
Smaller truths in the same spirit
The Epic landing forecast no longer mixes units when progress is measured in Features (ETAs were optimistic before). Capacity math in Next Sprint Planning no longer double-counts a personal day that overlaps a team day off, so it now agrees with the Sprint Capacity view. "All Teams" in User Metrics says "12 of N" when the view is capped. And DORA and Investment Allocation say so plainly if a team’s numbers had to fall back to project-wide scope instead of quietly relabelling them.
6.27.1: closed items no longer show as active
A patch release right behind 6.27 fixes a subtler case in the same spirit. Azure DevOps stamps every entry in a work item’s change history with the date of the change that followed it — not the date the change itself happened — and marks the newest entry with a far-future placeholder. We took those dates at face value, so an item whose very last change was being closed could keep showing as active — in the item timeline, Cycle Time, and sprint views — until anything else about it was edited, at which point it would suddenly snap to completed. A customer’s screenshots (a story closed weeks earlier, still reading "Active") pinned this down exactly. Every state change is now dated by its own recorded moment: closed items show as closed immediately, with the true completion date, and items that happened to be edited after closing lose the artificial extra days their cycle time had picked up. Some cycle times may read slightly shorter after this update — that is the more accurate number, not a change in your delivery. Nothing else moves: no settings, mappings, or stored data are affected.
Updating
The update applies automatically when you reopen the extension — nothing to install. The What’s New popup shows these highlights once. If your organisation has not yet approved the 6.26 pipelines permission, an admin approves it under Organization settings → Extensions → Agile Analytics → Authorize, and everything above arrives together. 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.