Why this release exists
6.15 came together as a focused stack of refinements that landed in customer conversations over the last two weeks. Three of them were direct customer reports — a trial admin watching the Cycle Time view on a brand-new ADO and seeing "verify your workflow mapping" when nothing was wrong yet; a sprint-summary user wanting to scope a multi-team view down to one project; a Configuration admin noticing that approving a pending user request didn't actually clear the badge on the nav until they refreshed the page. We bundled them with a handful of smaller fixes accumulated since 6.14 and shipped them together rather than dribbling out point releases.
"Limit to current project" toggle on Live Stats and Sprint Summary
Two of the most-used views — Live Stats and Sprint Summary — get a new "Limit to current project" toggle this release. When you've scoped the analytics layer to multiple teams across multiple projects, the per-team breakdown is often noisier than it needs to be — you came for this project's signal, not the whole organisation's roll-up. Toggling "Limit to current project" on filters the chart down to the project you're currently in, and the choice persists across sessions. Toggling it off restores the full multi-team view exactly as you had it before. There's no new setting in Configuration, no migration, and no admin step — the toggle lives right in the view alongside the other filters.
Empty Cycle Time on a brand-new ADO reads as a welcome, not a warning
Pre-6.15, opening Cycle Time on a brand-new Azure DevOps organisation with no sprints and no work items showed the same "verify your workflow mapping" message as a customer whose mapping was actually wrong. That was the right answer for the second case and the worst possible answer for the first — it suggested a configuration problem to a trial admin who'd done nothing wrong. The message now distinguishes between the two cases: if your mapping is configured and your team has some work items but none yet in a Done state, the verify-mapping CTA still appears — that's where it's genuinely actionable. If your mapping is configured and there are no work items at all in scope yet, the empty state reads "You're all set — waiting for completed work", with no CTA. Setup is correct, the chart is patiently waiting, and the admin sees a reassuring message instead of a confusing one.
Configuration signals that respect your time
Two related fixes on the Configuration sidebar. The badge count that surfaces pending admin actions — pending access requests, unrecognised workflow states — now clears the moment you finish the action, not after a page reload. Approving a user request, denying one, or saving a new workflow mapping triggers an immediate refresh of the badge state so the next thing you see is the empty Configuration nav, not a stale red counter. The workflow-mapping signal itself changed too: instead of a numeric count like "3" or "12", it now renders as a single "!" indicator. The number was visually conflating with the pending-access-request count next to it (the eye reads two adjacent red badges as one combined value), and the exact count was never actionable anyway — an admin opens the dialog once to review the whole list regardless of size. The pending-access-request count stays numeric because each pending request is a distinct human decision worth surfacing.
Smaller fixes that add up
- The Configure links inside chart empty-states now navigate from any view in the hub, not just from inside Configuration. Previously, clicking Configure on an empty Cycle Time chart while in Sprint Summary did nothing — now it works the way you'd expect from every view.
- Monte Carlo Forecast is now stable when you click "Run Forecast" multiple times on the same inputs. Two things were going on before: the single-team code path was hardcoded to a 14-day window while the date control defaulted to 30 days (the initial display and "Run Forecast" produced different numbers), and the simulation seeded itself with a fresh Math.random() sequence each click, so tail percentiles like 85% and 95% drifted by ±1 between identical runs. Both are now deterministic — same inputs, same numbers, every time, and admins on the same org get the same forecast as each other.
- Two noisy console log patterns got quieted: sprint API 404s during project switches (which were a race condition, not a real error) and repeated 400s from team-areas WIQL lookups. Both were cosmetic, but they cluttered DevTools sessions when customers were debugging legitimate issues.
- The React error boundary that catches a failed hub boot now uses the safer DOM API for rendering its diagnostic message — a defense-in-depth follow-through from the backend security audit. No user-visible change, but the error-fallback code path no longer interpolates strings into HTML.
Updating
Auto-update from the Marketplace; no admin action required. No new Azure DevOps scopes, no re-authorisation prompt, no consent screen. Every Configuration setting, license, workflow mapping, item-type mapping, access-control ACL, and dashboard preference is preserved exactly. The "Limit to current project" toggle defaults to off on first load, which matches the pre-6.15 behaviour — your existing multi-team views render unchanged. The first time you open the hub after the upgrade, the in-product changelog popup will show the v6.15.2 highlights once and then dismiss permanently. New installs: grab v6.15.2 from the Marketplace listing at https://marketplace.visualstudio.com/items?itemName=Baytek.agile-analytics.