🏠  ›  Documentation  ›  Admin & Setup  ›  Sprint Intelligence Setting

Sprint Intelligence Setting

Sprint Health Score blends 5 pillars — Schedule, Scope, Capacity, Risk, and Quality — into one 0-100 number for every sprint. Sprint Intelligence Setting is where you change how much each pillar counts, tenant-wide, instead of living with one fixed formula for every team.

In plain terms — this page holds 5 numbers that must add up to 100%. Raise Schedule's share and Sprint Health leans harder on pace-vs-time; raise Quality's and it leans harder on reopens and churn. Save applies the new mix tenant-wide, to every project and sprint, the next time a sprint's health score is recomputed — it never rewrites scores that were already saved.
⚖ 5 weighted pillars 🏢 Tenant-wide, not per-project 🔒 Separate View / Edit permissions

Why this matters: teams don't all agree on what "healthy" means. A team shipping fixed-scope compliance work may care far more about Schedule than Quality; a team doing exploratory feature work might weigh Quality and Risk more heavily. Before this setting existed, that judgment call was hardcoded — one weighting for every tenant, with no way to reflect what a given organization actually values.

SprintUnity Sprint Intelligence Setting — pillar weight sliders for Schedule, Scope, Capacity, Risk and Quality, with formula reference panel
🖼️ Screenshot coming soon
Sprint Intelligence Setting — Setup screen

Where to find it

Under Setup → Sprint Intelligence Setting, right below General Settings in the sidebar. The page header carries a badge that reads Default Weights whenever the 5 values still match the shipped defaults, and switches to Customized the moment any of them has been changed — a quick visual answer to "has anyone touched this?" without opening the form.

The 5 pillars and their shipped defaults

These are the weights every tenant starts on — the same numbers Sprint Health Score has always used, now exposed as a setting instead of a hardcoded constant:

PillarDefault weightWhat it measures
Schedule25%Remaining committed work vs. remaining sprint time.
Scope20%Definition of Ready (DOR) compliance across the sprint's issues.
Capacity20%Logged Dev/QA hours against the sprint's configured Sprint Capacity limits.
Risk20%The sprint's own Sprint Risk Score, inverted.
Quality15%Reopened issues and status-transition churn.

How each pillar's own 0-100 score is calculated

Changing a pillar's weight changes how much it counts toward the final Sprint Health Score — it never changes how that pillar's own score is computed. Those formulas are fixed and documented in full on the Sprint Intelligence & Health page; summarized here for reference:

Schedule

Compares how much committed work is left to how much sprint time is left. More work left than time left pulls the score down; no dates or commitment yet scores a neutral 100.

Scope

Penalizes issues that fail the same Definition of Ready check Risk Management uses. 100 means every issue in the sprint is DOR-compliant.

Capacity

Takes the worse of Dev/QA utilization against the sprint's configured limits. A healthy 70-100% band scores highest; no capacity configured scores a neutral 100.

Risk

The sprint's own Sprint Risk Score, inverted (100 − Sprint Risk Score) — a high-risk sprint pulls this pillar, and Sprint Health overall, down.

Quality

Penalizes reopened issues and status transitions beyond a normal To Do → In Progress → QA → Done lifecycle (about 3-4 transitions per issue).

The 100% rule, and Reset / Cancel / Save

A live Total badge next to Pillar Weights tracks the sum of all 5 fields as you type or drag — green at exactly 100%, red otherwise, with an inline warning banner underneath. Save Changes stays disabled until the total reads exactly 100% and at least one value has actually changed; there's no auto-rebalancing of the other 4 pillars when you adjust one; you decide where the remaining share comes from. Each pillar has both a slider and a paired stepper/number field, so you can drag roughly or type an exact value.

Reset to Defaults restores Schedule 25 / Scope 20 / Capacity 20 / Risk 20 / Quality 15 in the form — it doesn't save by itself; you still need to press Save Changes afterward. Cancel discards unsaved edits and restores whatever was last saved, without a confirmation step.

Tenant scope — not per-project, not per-sprint

This is one setting per Jira site, the same way General Settings is. There's no per-project override and no per-sprint override — every project and every sprint on the tenant reads the same 5 weights. Changing them here doesn't touch anything already saved: existing Sprint Health snapshots keep the score they were computed with; only the next time a sprint's health score is recomputed does it use the new weights.

Related score: Delivery Confidence stays fixed

Sprint Intelligence also shows a separate Delivery Confidence number alongside Sprint Health. It has always used its own weighting — Schedule 30% / Risk 30% / Capacity 20% / Stability 20% — and that stays fixed regardless of what's set on this page. The side panel labels it plainly: "Fixed — not editable here." The two scores measure different things (Sprint Health looks back at how the sprint has gone so far; Delivery Confidence looks forward at whether the forecast will land), so they were deliberately kept independent rather than sharing one weighting.

Permissions

PermissionWhat it controls
SprintIntelligenceSettings.ViewSee the page, the current weights, and the formula reference panel
SprintIntelligenceSettings.EditChange weights, use Reset to Defaults, and Save. Without it, the page shows every value read-only — no sliders, no stepper controls, just the current percentages.

Magic Wand

A single sprintIntelligenceSettings panel reports whether the 5 weights currently total 100%, whether the page still matches the shipped defaults or has been customized, and whether there are unsaved changes — plus a direct nudge to adjust the pillars if the total is off, so you don't have to hunt for which value is throwing it off.

Who uses this, and why

Application AdministratorsTune the one tenant-wide weighting once, based on what actually matters for how this organization runs sprints, instead of accepting a one-size-fits-all default.
Team LeadsUnderstand exactly why a sprint's health score reads the way it does — the formula reference panel is the same math the score is built from, not a simplified summary.
New tenantsShip on sensible defaults (Schedule 25 / Scope 20 / Capacity 20 / Risk 20 / Quality 15) from day one, with nothing to configure until there's a real reason to.
Benefit to the team — Sprint Health stops being a black-box number and becomes a weighting the organization itself set and can explain, with the exact formula behind every pillar sitting right next to the controls that change how much it counts.

What's deliberately left out, and why

  • No per-project or per-sprint override — this is intentionally one tenant-wide value, the same way General Settings works, not a setting that could quietly diverge project by project.
  • No auto-rebalancing — raising one pillar never automatically lowers another to keep the total at 100%. You choose the trade-off explicitly.
  • Delivery Confidence's own weighting isn't editable from this page, or anywhere else today — it's fixed by design, not an oversight.
  • Saving doesn't retroactively recalculate any sprint's already-stored Sprint Health snapshot — only sprints computed after the save use the new weights.

Rating this page

Anyone reading this documentation can mark whether it answered their question — no permission required. It only helps the SprintUnity team see which pages need more detail.

Was this page helpful?
Thanks — your feedback was recorded.