Enterprise package update (6.43.0)
Organisation-wide governance for Agile Analytics for Azure DevOps.
This release turns Agile Analytics from something each person configures alone into something an organisation can govern. An admin can now set one baseline for the settings that decide what the numbers mean, publish that baseline to people who already have their own, allow specific projects to differ where they genuinely do, lock the settings that must match everywhere, see by name who has picked a change up, and export a record of every administrative change. The same release also carries a set of accuracy and reliability improvements that apply to everyone.
Setting a baseline changes nothing for anyone already using the product. It only decides what someone starting fresh inherits. Reaching people who already have their own settings is a separate, deliberate action.
1. For admins: what you can now do
Everything below lives in Configuration, on the Enterprise tab, and is available to organisation admins.
- One organisation baseline
Set the reliability, churn and carryover targets, the display units, the weekend rule, the teams the organisation watches, and the work item types the charts count, once, for the whole organisation. When every team measures the same way, a comparison between two teams reflects the teams rather than their configuration.
- A faster start for new people
Anyone opening Agile Analytics for the first time inherits the baseline instead of an empty form. That removes the setup conversation from onboarding and stops each new joiner from quietly inventing a slightly different definition of the same metric.
- Apply to everyone, on purpose
Reaching colleagues who already chose their own settings is its own action, with its own confirmation, and you choose which fields it covers. Saving a baseline never reaches them on its own. Governance stays something you decide to do, not something that happens while you are editing a form.
- Per-project overrides
A project that genuinely works differently can override individual fields on top of the baseline. Fields the project leaves alone keep following the organisation baseline, including after the baseline later changes. You get one standard with named exceptions instead of either forcing every team to match or letting every team drift.
- Locks for the settings that must match
Lock the fields where a difference between projects would make the organisation-level numbers meaningless, and every project uses the baseline value for them. Unlocking later restores a project’s stored override without anyone re-entering it, so a lock is a policy decision you can reverse rather than a one-way deletion.
- Adoption you can see by name
After you apply settings to everyone, the Enterprise tab shows who has picked the change up, by name, with a total and the time of the most recent pickup. Rollout stops being a guess. That record is written into your own Azure DevOps organisation, where your admins can read it, and it stays there.
- An activity log with CSV export
Every baseline save, project override, lock change and publication is recorded in your organisation’s admin activity log, and the Enterprise tab exports its own view of that log to CSV. When someone asks who changed the reliability target and when, the answer is a file rather than a recollection.
2. What your team members see
When an admin applies settings to everyone, nothing is written into anyone’s account behind their back. Each person collects the change themselves, the next time they open Agile Analytics, and they see exactly what happened before they decide.
A banner appears at the top of their next page load, naming the settings the admin set. It reads like this:
Your admin set new organisation defaults for: Live Stats teams
Some of your settings were replaced.
- It names the settings, not just the fact of a change
The banner lists which settings the admin set, so a person can tell at a glance whether this affects the view they rely on every morning or something they have never opened.
- It says plainly that some of their settings were replaced
There is no ambiguity to work out. The banner states that some of their own values were replaced by the new organisation defaults.
- Two buttons, and both of them work
"Keep mine instead" brings their previous values back exactly as they were. "Use the new ones" accepts the organisation defaults. Either way the person chooses, and the choice takes effect immediately.
- It is honest about what gets recorded
The banner states that picking the change up is recorded, with the time, in your organisation’s own log, where your admins can see the person’s name. Nobody discovers that after the fact.
Where that information goes
That record is written to your own Azure DevOps organisation and stays inside it. Your admins are the audience for it. It is not sent to Baytek and it is not sent to any third party.
Nothing changes silently
The design principle behind the whole feature is that a person’s own setup is never discarded without being offered back to them. An admin can move the whole organisation to a shared standard, and the people affected still see what changed, still hold the undo, and still find their previous values waiting if they want them. Governance and trust are not a trade here. You get both.
3. Reliability improvements in this update
These apply to everyone using Agile Analytics, whether or not your organisation uses the Enterprise tab.
- User Metrics shows your people
The User Metrics view now returns the named contributors it was always meant to show, in every organisation. Anyone who saw only a single unassigned row will see their team.
- Dashboard widgets ask for what they need
A widget tile added to an Azure DevOps dashboard without a team selected now says so and prompts for configuration, instead of sitting on a loading state.
- Applied settings appear straight away
When an admin applies settings to everyone, the result is visible in the admin’s own session immediately, with no reload. Saving a baseline also states clearly that people who already have their own settings are unaffected until you apply to everyone.
- Each settings tab saves only itself
Saving one Configuration tab no longer commits unsaved edits sitting on another tab. What you save is what you looked at.
- Clearer limits on number fields
Numeric settings now show the values they accept and correct an out-of-range entry when you leave the field, rather than changing what you typed while you are typing it. Service level expectation targets validate their range on entry.
- Translations across all six languages
A large set of previously untranslated labels and messages is now translated in every language the product supports, so a non-English organisation sees fewer English fragments in an otherwise translated screen.
- Copy to clipboard works inside Azure DevOps
The copy buttons, including the ones used to move webhook and integration values around, now reliably place their content on the clipboard when the product is running inside Azure DevOps.
A correction to Flow Efficiency
One accuracy fix in this release changes numbers you have already seen, so it is worth reading before you compare this month to last. Where a workflow state had at some point been treated as review time, that classification could persist after the workflow moved on, and the affected work was counted as waiting when it was not. The classification is now corrected. Organisations carrying that effect will see Flow Efficiency rise, and cycle time and wait time fall, the next time the views load. Nothing needs to be done to apply it, and the movement reflects a more accurate reading rather than a change in how your teams worked.
4. Getting started as an admin
The sequence that works: confirm the workflow mapping on a couple of representative projects first, save the baseline and leave it to seed new people for a while, then apply to everyone once you are confident in the specific fields you want everybody to share. A baseline built on top of a workflow mapping that is not yet right will standardise the wrong numbers across every team at once.
The full walkthrough: setting the baseline, applying it to everyone, per-project overrides and locks, what a publication never touches, and a rollout sequence for a large organisation.
Day-to-day administration: access control, seats, group rules, workflow mapping, and the organisation-wide activity log with its unfiltered export.
Questions?
If you would like a second pair of eyes on your rollout, or you have a question about anything in this release, email us.
license@baytekdev.com