Scoring Release Risk Before You Ship

Overview

The Release risk calculator (on the Quality tab) scores a proposed changeset — before it merges — and recommends how carefully it should be reviewed. It's a fast gut-check: describe the size and shape of a change, and StretchDev returns a risk score out of 100, the total churn, the factors that drove the score, and a recommended review path.

Release-risk scoring is a pure, read-only computation — it never writes a scan or changes your data — so you can score the same change as many times as you like while you tune it.

Score a changeset

1. Open the Quality tab and scroll to the Release risk panel.
2. Enter the shape of your changeset:
- Files changed — how many files the change touches.
- Additions — lines added.
- Deletions — lines removed.
- Complexity delta — the change in cyclomatic complexity.
- Hotspots touched — how many known risky areas the change hits.
- Tests changed — how many tests were added or modified.
3. The score updates as you type. Read the three result tiles:
- Risk score — a value out of 100.
- Churn — total lines changed (additions + deletions).
- Review — the recommended review path (for example, Standard, or a heavier path for risky changes).
4. Below the tiles, StretchDev lists the factors that drove the score, so you can see why it landed where it did.

Read the risk level

The panel header shows an overall risk level chip (for example, Low, Medium, or High) summarizing the score at a glance. Broadly: large churn, rising complexity, and touching multiple hotspots push the score up, while changing more tests pulls it down.

Example

A large refactor with no test coverage:

This scores High — large churn (2,400 lines), rising complexity, three hotspots, and zero test changes all push the score up, and the recommended review path escalates beyond Standard. Split into three smaller changes with tests, each piece re-scores far lower.

Use it in your workflow

1. Before opening a change for review, plug its stats into the calculator.
2. If the score comes back High, split the change into smaller pieces, add tests (raising Tests changed lowers risk), or route it to a more thorough review.
3. Re-score after adjusting to confirm the risk dropped, then proceed.

Tip: Adding tests is the cheapest lever for lowering a risk score. A high-churn change with strong test coverage almost always scores lower than a small change that touches a hotspot with no tests at all.

Tips

• Keep changes small and focused — churn is a major driver of the score.
• Treat hotspots touched seriously; changes to known-risky areas warrant deeper review even when they're small.
• Feed real numbers from your version-control diff for an accurate score.
• Pair the risk score with the project's quality gate: the gate judges the code's current state, the calculator judges the shape of the incoming change.

Troubleshooting

• The panel says intelligence is unavailable. Release-risk scoring requires the analysis engine; ask an administrator to enable it.
• The score seems stuck at zero. All inputs may be zero or blank — enter the actual counts for your change.
• The recommended review path feels too strict. Reduce risk at the source: split the change and add tests, then re-score.