Don't Ask What to Retest. Ask What the Removed Layer Touches.

A managed package was coming out of the org. Pricing and billing components that half the platform had been built on top of.

The instruction was "full regression." Three teams, more than six hundred delivered stories, one release window.

Full regression, read literally, means retesting everything ever delivered. That is not a plan. It is a wish with a deadline attached.

The Question That Makes It Finite

We stopped asking what should we retest and asked a different question:

What does the removed layer touch?

Then every delivered epic across all three teams went through a single triage: does this touch order, asset, pricing or billing? Yes or no.

That one question splits the org into two tiers, and the tiers carry their own rules.

Core — direct blast radius. Everything that touches the removed layer. Authored first, one happy path per functional variant.

BAU — everything else. In scope for one honest reason: we cannot predict every dependency. One happy path per sub-module, and no more.

The result was a master scope of 161 variants, each mapped to the stories it covers, each carrying a reuse flag for cases that already existed.

Why the Tiering Does More Than Prioritise

The two tiers give you three things for the price of one triage question.

Scope. Everything is in, but at different depths. Nobody has to argue that a module is unimportant — a painful conversation that a binary in/out decision forces you to have with every team lead.

Authoring order. Core first, because that is where a defect is likely and where a late finding hurts most. When the schedule slips — and it will — you slip BAU, which was thin by design.

Depth rule. Core gets one happy path per functional variant. BAU gets one happy path per sub-module. The depth is decided once, by tier, instead of being negotiated case by case for 161 items.

That last one is where most regression planning quietly dies. Not in choosing what to cover, but in relitigating how deeply to cover each thing.

The Justification You Can Say Out Loud

"We cannot predict every dependency" is not a weak reason for including BAU coverage. It is the honest one, and stating it plainly does two useful things.

It explains why the coverage is thin — you are not trying to validate those modules, you are trying to detect surprises.

And it puts the risk where it belongs. If something breaks in a BAU module that had one happy path, the answer is not "QA missed it." The answer is "we accepted thin coverage there, deliberately, for this documented reason." That conversation is survivable. The one where nobody wrote the reason down is not.

Then Reconcile Against What Already Exists

Here is where I got humbled.

A scope built top-down from delivered stories looked complete. We cross-checked it against a sanity suite written years earlier by people who had long since left.

It lost five times.

Five themes in that old suite had no home in the new scope. Parental controls. Early termination outside the cool-off window. A router upgrade fee. A contact information document. And a customer rejecting a modification.

Nothing in the delivered-stories view surfaced them. They were things the organisation had learned by being hurt, and that knowledge lived in the suite rather than in any requirement.

A new regression scope is not finished until it has been reconciled against the suites that already exist. Top-down scoping tells you what was built. Existing suites remember what broke.

When a Design Rule Should Bend

The fifth of those themes forced a decision.

The suite was deliberately happy-path only — a rule chosen on purpose, to keep 161 variants achievable. But "customer rejects the modification order" is a negative path important enough that leaving it out was worse than breaking the rule.

So we broke it. Once. Explicitly, with the reason recorded next to the variant.

That distinction matters more than it sounds. A rigid rule gets quietly violated by whoever is under pressure at the time, and after five silent exceptions there is no rule left. A rule that bends once, on the record, with a stated justification, survives — because the exception is visible and everyone can see the bar it had to clear.

A documented single exception beats both a rigid rule and silent erosion.

The Method, Compressed

• Ask what the removed or changed layer touches. That is your triage question, and it should be answerable yes/no from an epic title plus thirty seconds of thought.
• Make everything it touches Core. Author it first, at depth.
• Let everything else in as thin BAU coverage, justified explicitly by dependency uncertainty.
• Map every variant back to its stories, and flag what can be reused.
• Reconcile against every existing suite before you call the scope done.
• Where a rule has to bend, bend it once and write down why.

None of this requires a tool. It requires one question asked six hundred times, which took two days and made every subsequent argument about scope resolvable in a sentence.

If a platform component were removed from your org tomorrow, could you answer — in one page — what it touches?