Standardising Agile Analytics across your organisation
When 40 teams compare numbers, the comparison only means something if “what counts as a story” and “which states mean in-progress” mean the same thing everywhere. This is how the Enterprise tab sets an organisation-wide baseline, rolls it out to people who already have their own settings, and lets one team genuinely differ without breaking that comparison for everyone else.
1. Why organisation defaults matter at scale
A single team can set its own reliability target, decide which board column means “in progress,” and pick its own work item types without anyone else noticing. Forty teams doing that independently is a different problem: the moment someone compares cycle time or reliability across teams, every difference in configuration shows up as if it were a difference in performance. The Enterprise tab exists to give an admin one place to set what “good” and “in progress” mean for the whole organisation, roll that out deliberately, and still let a genuinely different team diverge on purpose rather than by accident.
2. Walkthrough: baseline to adoption
Five steps, in Configuration → Enterprise, from setting the baseline to seeing who has actually taken it.
- 1. Set the organisation baseline
Open Configuration → Enterprise with the project selector left on "Organisation baseline." Set dashboard thresholds (reliability, churn, carryover targets), WIP Monitor display settings (teams shown at once, sort order, threshold mode), display units, weekend exclusion, which Live Stats and scope/completion teams the organisation watches, and which work item types the charts count.
- 2. Save seeds new people only
Save writes the baseline document but never bumps its push revision — the mechanism "Apply to everyone" alone controls. That means Save cannot reach a single person who already has their own settings; it only changes what someone starting fresh in Agile Analytics for the first time inherits.
- 3. "Apply to everyone" reaches existing people
Tick which of the ticked-and-set fields you want to overwrite for people who already chose their own, confirm the values you are about to publish, and click through. Nothing is instant — an admin cannot write into another person’s settings directly, so this bumps the baseline’s revision and each person’s own Hub collects it the next time they open Agile Analytics, exactly once per person.
- 4. Every recipient gets a named-field undo
Anyone whose settings actually changed sees a banner naming which fields moved (falling back to a generic sentence only for a push published by an older version of the extension), with a one-click "Keep mine instead." There is no admin-side way to recall or cancel a push once it is sent — the recipient’s own undo is the only way a pushed value gets reverted.
- 5. Who’s picked it up
The push panel counts people who have collected the current revision by name, growing as each person opens Agile Analytics after the push. It never claims a denominator — the organisation’s full member list is not knowable from here, so the count only ever says how many have picked it up, never "4 of 20."
3. Per-project overrides
When one team genuinely differs, a project can override specific fields on top of the organisation baseline — one baseline, with explicit exceptions, rather than either forcing every team to match or leaving every team to drift.
Blank fields stay live, not snapshotted
A field a project leaves blank keeps following the organisation baseline — including after the baseline later changes. This is resolved live, not snapshotted: an override is not "the baseline as it stood on the day someone opened the form," it is "whichever sub-keys this project actually chose to set," with everything else tracking the baseline forever.
Locks stop project-level divergence
A lock applies at the organisation baseline and stops any individual project from overriding that field — every project uses the baseline value for it, and a new person starting fresh in a locked project inherits the baseline too. A lock does not touch any existing user’s own personal settings; those only change when an admin explicitly pushes the field with "Apply to everyone," or the person opts in themselves. Locking or unlocking a field never discards a project’s stored override — it only changes whether that override is currently honoured, so unlocking later restores it without anyone re-entering the value.
4. What the push deliberately never touches
- Personal channel wiring
Notification channels are deliberately excluded from the settings an organisation can standardise at all — defaulting them would mean sending Teams or Slack messages on someone’s behalf, which the product treats as always a personal act. Anything a stored default carries that looks like channel wiring is stripped before it can be saved.
- Alert schedules
A team’s Sprint Transition Monitor schedule is bundled with that team’s channel wiring, not with the display settings an organisation may push. The same stripping applies here, so a baseline field can never smuggle someone else’s alert timing into your settings.
- Monitor pipelines
The Azure DevOps pipeline id behind a person’s own WIP or Sprint alert monitor travels with that person’s team setup, never with an organisation default. When a push does touch the watched-team list, it deliberately keeps any extra team a person’s own monitor already depends on, so their alerts keep arriving instead of going silent the next time they open the Hub.
That is the coherence guarantee behind the whole feature: an admin can standardise what counts as reliable, what "in progress" looks like on the WIP board, and which teams and work item types the organisation measures — without a single person’s alert setup, channel, or monitor pipeline being touched, pushed, or even eligible to be touched.
5. Governance
Reading or writing the organisation baseline, project overrides, or locks all sit behind the same admin-editing guard the extension’s other organisation-scoped tabs use. A non-admin sees the tab, never a way to change what is in it.
Every baseline save, project override, lock toggle, and push appears in the same admin activity log the rest of the extension shares. The Enterprise tab shows a filtered view — this surface only — with its own CSV export button that exports exactly that filtered view. For the organisation’s whole admin history in one export, use Access Control’s unfiltered activity log (see the Administrator Guide), which includes these same Enterprise entries alongside every other surface.
The baseline, the per-project overrides, the locks, and the adoption ledger all live in your organisation’s own Azure DevOps storage. When someone collects a push, that fact is recorded with a timestamp in your organisation’s log, where your admins can see the name — it stays in your Azure DevOps organisation and is never sent anywhere else.
This is an operational control, not a security boundary: your Azure DevOps organisation storage can be written by any member of the organisation. The Enterprise tab decides what a new person inherits and what an "Apply to everyone" push publishes — it does not, and cannot, restrict what Azure DevOps itself lets a member of your organisation do.
6. A rollout recipe for a 40-team organisation
None of this is enforced by the product — it is a sensible sequence for a large rollout, not a built-in wizard.
- 1. Pilot on two projects
Pick two representative projects and confirm each team’s workflow mapping is right first (see the Administrator Guide) — a baseline built on top of a wrong workflow mapping standardises the wrong numbers everywhere at once.
- 2. Set the organisation baseline
Once the pilot projects confirm the thresholds, WIP display settings, watched teams, and counted work item types make sense, save them as the baseline. This step alone changes nothing for anyone already using the product — it only sets what new people inherit.
- 3. Publish deliberately, not by default
A push always reaches the whole organisation in one action — there is no built-in way to publish to one project or one wave of people at a time. Treat the pilot as validation, then use "Apply to everyone" once, for the fields you are actually confident in, rather than relying on the product to stage a rollout for you.
- 4. Watch who’s picked it up
After a push, check the adoption count and named list on the Enterprise tab over the following days. It only ever grows as people open Agile Analytics — there is no reminder or notification, so build a habit of checking rather than expecting a signal.
- 5. Use per-project overrides for genuine exceptions
If a specific team still needs to differ after the baseline is live, override just that field on their project rather than re-opening the organisation-wide conversation. Lock a field instead if you need every project to match with no exceptions.
A push always reaches the whole organisation in one action.
There is no built-in way to publish to one project or one wave of people at a time. “Push in waves” here means staging by field — publishing the settings you are confident in, then adding more later — not staging by audience or percentage.
Need help?
Our support team is available Monday through Friday, 9 AM to 5 PM Pacific Time.