Scope Control: Cut Rules Before You Need Them

What This Concept Is

Scope-cut rules are a pre-written list of features and refinements you will drop if the capstone starts slipping -- written in week 1 while you are still optimistic and your judgment is clear. The list is ordered: first to cut at the top, last to cut at the bottom. The core MVP and the quality gates are explicitly never on the list.

Each rule has exactly two fields:

• Cut condition -- a specific, observable signal that triggers the cut. "If end of week 3 and the deploy pipeline is not green," not "if things feel bad."
• What gets cut -- the named feature or the concrete scope reduction, tied to a file, a test, or a line in the design doc. Not "reduce ambition."

The list is a form of Ulysses pact: your week-1 self, binding your week-5 self. Week-5 you is tired, invested, and optimistic about 12-hour days. Week-5 you will refuse to cut things that week-1 you would have happily cut. The list takes the decision away from week-5 you.

There is a third discipline in the list, less obvious but equally important: quality gates are above the line -- uncuttable. When scope is cut under pressure, the natural instinct is to cut tests, skip the runbook, drop the health check, delete the fitness function. These are invisible losses -- nobody sees them in the demo -- which is exactly why they are the dangerous ones. Pre-writing the list forces cuts to come from features, not from rigor.

The list sits next to the schedule (concept 13). The schedule tells you when you are slipping; the cut list tells you what to do about it. Without the cut list, "I'm slipping" is anxiety; with it, it is a procedure.

Why It Matters Here (In the Capstone)

The capstone is the first place many learners practice shipping. Shipping is not "finishing the plan" -- shipping is "choosing what to keep and what to drop so that what is delivered is whole." Every professional engineer does this weekly. The capstone is where you do it for the first time with your own name on the artifact.

The second reason: scope control is the single skill that most distinguishes a capstone that reads as mature engineering from one that reads as student work. A capstone with four clean features + tests + runbook reads higher than one with six features half-broken and the runbook "to be added." The grader knows what shipping looks like.

The third reason: the cut list transforms the week-5 narrative. Without it, week-5 you either overworks into burnout or silently descopes in panic. With it, week-5 you makes a pre-committed decision, logs it, updates the ADR -- and the capstone gains a truthful, self-aware record of its own evolution. That record is gold in the defense.

Concrete Example(s) -- from a real capstone

Example A -- inventory service scope-cut list:

Order	Cut condition	What gets cut
1	End of week 2, MVP not deployable locally	Drop "CSV bulk import." Scan-only receiving is the MVP.
2	End of week 3, staging not deployed	Drop "low-stock email alerts." /health endpoint stays.
3	End of week 3, still not deployed	Drop "supplier reconciliation report" (retain owner reconciliation only).
4	End of week 4, load p95 > target	Relax p95 from 300ms to 500ms. Update ADR-001 consequence.
5	End of week 4, concurrency bug on reservations	Drop "multi-user edit" for MVP. Single-writer only. Document in ADR.
6	End of week 5, anything still burning	Drop "audit log UI" -- retain the DB table, cut the viewer page.
Never cut	--	Scan -> OnHand vertical slice. Idempotency fitness function. /health post-deploy check. Three ADRs current. Design doc current. One observability surface.

Example B -- ticketing platform scope-cut list (different domain, same shape):

Order	Cut condition	What gets cut
1	Week 3 end, QR round-trip not passing integration test	Drop custom-branding feature (single template remains).
2	Week 3 end, concurrency test still flaky	Cut "multi-tier pricing" -- single flat price per event.
3	Week 4 end, door-scan offline mode not working	Reduce to online-only door scan. Update ADR-001 consequence.
4	Week 4 end, tests below 70% on core	Drop "ticket transfer" feature entirely.
Never cut	--	No-oversell invariant + fitness function. QR scan-uniqueness. /health. Three ADRs. Design doc.

Example C -- finance aggregator cut decision in action (week-4 journal excerpt):

Week 4 Friday: rules engine is 60% done. Integration tests flaky.
Scope-cut rule #3 triggered (flaky rules engine by end of week 4).
Action: cut "rules inheritance across accounts." Retain per-account rules.
Updated design-doc Section 10 (non-goals): "rules inheritance -- future work,
privacy implications make it not a week-6 feature."
Updated ADR-002 consequence: "rules engine stays flat per account."
Commit: cut: drop rules inheritance (scope rule #3)

The commit message names the rule that triggered. Six months later, reading back, the decision is self-explanatory -- not folklore.

Common Confusion / Misconceptions

• "I'll decide what to cut when the time comes." Your judgment under pressure is worse, not better, than your judgment today. The whole point is pre-commitment. Real-time cut decisions systematically preserve the wrong things.
• "Cutting is failure." Cutting is engineering. A shipped capstone with four features is better than a broken capstone with six. Cutting scope is what every senior engineer does every week of their career -- the capstone is where you rehearse it.
• "I'll cut tests first -- they're slow to write." This is exactly the instinct the list prevents. Tests protect the grader-visible behavior; cutting them cuts the capstone's defensibility, not its scope.
• "The cut list is negative thinking." Opposite: writing the list is what lets you be genuinely ambitious on the uncut features, because the safety net is defined and named. Ambition without an exit plan is anxiety.

Quality Gates That Never Move

Certain gates are load-bearing for the capstone's defensibility. They stay even when everything else is on fire:

• The MVP vertical slice runs end-to-end on the demo environment.
• Every happy-path step in the MVP is covered by at least one automated test.
• A /health endpoint or equivalent returns 200, verified after every deploy.
• The design doc, three ADRs, and risk register are current (they reflect what was actually built).
• At least one fitness function passes in CI.
• One form of observability (minimum: structured logs with request IDs) is live.

If you are considering cutting any of these, something much earlier went wrong. The correct response is not to cut the gate but to cut another feature harder.

Communicating Cuts

When a cut triggers, the record is as important as the cut itself. A cut that was invisible to the reader looks like a bug; a cut that was documented looks like engineering maturity.

1. Strike through the feature in the design doc, leaving the strikethrough visible.
2. Supersede or amend any ADR that referenced the feature.
3. Commit with a message that names the triggering condition: cut: drop CSV import (scope rule #1 -- end of week 2).
4. Add one sentence to the Non-Goals section explaining the cut's rationale in characteristics terms ("cut because operability driver forbids unproven path under week-5 time pressure").

How To Use It (In Your Capstone)

1. List every backlog item. Classify each as core MVP (uncuttable), nice-to-have (cuttable), or already feature-creep (cut now).
2. Rank the cuttables by a mix of least user impact and largest schedule relief. Most-expendable at the top.
3. Write the cut condition per row. Tie each condition to a specific week-end and a specific observable signal -- never to mood.
4. Commit the list to library/raw/scope-cuts.md or to a dedicated section of the design doc. Public, version-controlled, irrevocable.
5. Do not re-read the list until a condition triggers. Obsessing over it weekly corrodes the pre-commitment.
6. When a cut triggers, cut. No renegotiation. Update ADRs, design doc, and risk register the same day.
7. Keep the "never cut" row above the line. If it is in danger, the answer is to cut harder from the nice-to-haves, not to demote the gate.

See also (integrative)

Scope control is the operational form of risk-driven prioritization (S7 M05) and the iteration ethos (S8 M01).

• S7 M05 -> Risk-driven review: RCDA prioritization -- use when ranking cuttables. Highest-impact uncertainty stays; low-impact polish goes.
• S7 M05 -> Superseding, amending, and ADR status lifecycle -- use when a cut invalidates an ADR claim. Supersede, never delete.
• S8 M01 -> Articulating tradeoffs: why this, not that -- use when justifying a cut in the defense. Every cut is a trade-off made visible.
• S8 M05 -> Stakeholder mapping and alignment -- use when deciding what to cut to (the alternative), not just what to cut.
• S3 M05 -> Over-engineering vs under-engineering: reading the context -- use when remembering this pattern is universal, not capstone-specific.

External references (curation-validated this session):

• Eric Ries -- What is an MVP? -- use when keeping your cuts aligned to learning, not pride.
• Henrik Kniberg -- Making sense of MVP (skateboard -> bicycle -> car) -- use when you need the shipped-and-useful frame for what "cut to" means.
• Martin Fowler -- YAGNI -- use when a "nice-to-have" is actually speculative. YAGNI lets you cut it pre-emptively.
• Google SRE -- Embracing Risk & Error Budgets -- use when framing the "what we are prepared to lose" conversation with yourself.
• Martin Fowler -- MaximizingTheWorkNotDone -- use when you suspect cutting is virtuous. It is.

Check Yourself

1. Name the first feature on your capstone cut list and the specific signal that triggers its removal.
2. What is never on the cut list, even at 11pm of week 5?
3. Why are quality gates (tests, health check, fitness functions) above the line?
4. When a cut triggers, what two artifacts must be updated the same day?
5. Can you rehearse the defense sentence that explains any cut without apologizing for it?

Mini Drill or Application (Capstone-scoped)

• Drill 1 (25 min). Write your cut list in library/raw/scope-cuts.md. At least 5 cut rows plus the "never cut" row. Each row: specific condition + specific feature/scope reduction.
• Drill 2 (5 min). Promise yourself in writing (in the file, top of doc) that you will not renegotiate the list mid-crisis. Commit.
• Drill 3 (15 min). For each "never cut" item, write one sentence explaining why cutting it would collapse the defense.
• Drill 4 (10 min, end of each week). Check whether any condition triggered. If yes, execute the cut that same evening -- no overnight reconsideration.
• Drill 5 (10 min, week 5). Draft the two-sentence defense explanation for the most likely cut. Rehearse it.

---

Source Backbone

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.

• Fundamentals of Software Architecture - architecture characteristics, styles, and tradeoffs.
• Learning Domain-Driven Design - domain discovery, subdomains, and bounded contexts.
• Clean Architecture - dependency direction and boundary discipline.
• API Design Patterns - contract and API decision support.