Cutting Scope Without Cutting the Point

Eleven cuts a published case made and four it refused, each run through one test: on release day, is the problem the work exists to fix still there?

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources, namely a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, no interview. The case cuts a lot: its scope section excludes five things, its to-be lists seven it deliberately did not change, and its one-page summary sends the largest option to the back of the queue. Here those cuts meet four the case refused, under one test.

Cutting scope without cutting the point means removing work whose absence still leaves the problem fixed on release day, and refusing any cut after which the problem statement would still be true.

In short

• Before the first cut, write the point as two sentences: the problem release day must make false, and the anti-goal the work must not reach by accident.
• Eleven cuts in the case pass that test, in four shapes: excluded with an owner, left unchanged with a reason, parked with a date, deferred behind a measurement.
• Four tempting cuts fail it. The most dangerous keeps the requirement's title and drops one prohibition from one criterion.
• Compare the cut-down release with what customers have today, not with the full design.

What is "the point", in a form you can cut against?

A feature list cannot tell you which cut hurts. You need a sentence that the release is supposed to make false. The case has one, in section 1.3:

A damaged-delivery case that lacks sufficient evidence at the first call has no named owner and no due date.

Section 1.4 adds the second sentence, the anti-goal: "I am not trying to reduce the number of refunds." The reason sits beside it: "the most efficient way to reduce refunds is to make claiming one harder, and that is the failure mode this work could most easily produce."

Those two lines give three questions to ask of any proposed cut:

1. Point. On release day, with this cut made, is the problem statement still true? If yes, the cut took the point with it.
2. Anti-goal. Does the cut make a refund harder to claim for anyone still in scope?
3. Guard rail. Does the cut remove the way back from a risk the rest of the change creates? Section 3.5 of the case lists three such risks under "What the to-be makes worse".

A fourth column is bookkeeping, and it matters as much: where the cut thing goes. The case draws that line between its exclusions and its undecided items: "Items in the first table are gone. The item in the second one is coming back, and it will come back at the worst possible moment unless it has a date on it."

The Scrum Guide has the same structure at sprint level: "Scope may be clarified and renegotiated with the Product Owner as more is learned", but "No changes are made that would endanger the Sprint Goal". That only works when the goal is written so you can tell whether a change endangers it. "Improve the refund process" is endangered by nothing, so no cut ever looks wrong against it.

Eleven cuts the case made, and why each one passed

Every row is in the published case. Quoted reasons are the case's; "my reading" marks mine.

Read the "Shape" column on its own. Excluded means gone, with somebody else holding it. Left unchanged means looked at and kept, with a reason. Parked means it comes back on a date, with a fallback if the date passes. Deferred means a named number reopens it.

None of the eleven touches what the point needs: a named owner and a due date on a stalled case. That is why the list can be long without the release getting thin.

Row 2 deserves a second look. It came from a reviewer rather than from me (RL-04), and of the eleven it comes closest to the anti-goal. Section 3.5: "Self-service moves evidence work onto the customer. Someone whose parcel never arrived has nothing to photograph, and on the phone they at least got a human." The case named the group out of scope with an owner, and kept the phone line, "the only channel for anyone the form does not fit". The exclusion is safe only because something else stayed.

Scorecard check 11 asks for this visibility: "The to-be states what changed against the as-is, and what deliberately stayed the same." A visible cut can be argued with. The one that hurts is the one nobody wrote down.

Four cuts the case refused, and the test each one fails

Each would save real work, and each is refused by a line already in the case.

The second row is the dangerous one, because it does not look like a cut. The requirement keeps its title, Escalation ownership, and stays a Must. The register index reads the same before and after. What disappears is one sentence in one criterion, and with it the point. The case says why that criterion is a prohibition: "a queue satisfies the sentence 'the case is assigned' while changing nothing at all."

A cut at that level never reaches a scope meeting. It happens in build, when a rota turns out harder to configure than a queue. The defence is to read the point sentence against the criterion text, not the requirement title: if this sentence is softened, is a stalled case still without a named owner? If yes, the softening is a scope cut and needs the same decision as any other.

The fourth row is covered in MoSCoW or WSJF: both requirements are bound to change 1 and ship with it.

Why compare the cut version with today, not with the full design?

Basecamp's book Shape Up has a chapter on this called Decide When to Stop. Its advice is to "compare down to baseline", meaning the current reality for customers, instead of up against the ideal: "It's the difference between 'never good enough' and 'better than what they have now.'"

Against the full design, every removal is a loss and the argument becomes a negotiation about how much loss is acceptable. Against today, the question is whether the reduced release still beats what a customer with a broken parcel gets now.

Row 10, the status tracker. Against the full design, cutting it is a real loss. Against today, where the as-is model shows the customer chasing, REQ-015 criterion 3 already sends "one message naming the person holding the case and the date by which they will hear back." The part of a tracker the point needs ships anyway. That reason is mine; the case's is that the first two changes get measured first. Both hold.

Option A. Against the full design, it looks like a cheap step in the right direction. Against today, the case gives its effect as "None that anyone will notice". A cut that leaves the release level with the baseline has removed the point, however tidy the release notes look, and only the baseline comparison shows it.

The scope cut ledger, filled

Written for this piece from the case record. The case has no ledger, its cuts are spread across four sections, and its two reviewers never saw this sheet.

Point: A damaged-delivery case that lacks sufficient evidence at the first call has no named owner and no due date.

Anti-goal: Refunds fall because claiming one got harder.

"Not assessed in the case" is deliberate: the case never says whether dropping partial refunds makes a claim harder, and I will not fill that cell from my own head.

The scope cut ledger, blank

Copy it to the top of your scope section. Fill the two lines above the table before the first row, or every cut will pass.

Point: [The problem in one sentence, written as it reads today. If the release works, this sentence becomes false]

Anti-goal: [The cheapest way to make your success measure look good while making the business or the customer worse off]

Two rules: a cut with an empty "Where it goes" cell is an omission, and it will come back unannounced. And run the ledger at criterion level too, because the cut that kills the point usually lives inside a criterion that kept its heading.

Where is this method weak?

The test is only as good as the point sentence, and here the author of the point sentence also made the cuts. A reviewer who read the problem differently, say someone who sees the threshold as the real issue, would draw a different point and fail different rows.

The ledger says which cuts are allowed, not which to make first; that is sequencing, covered in MoSCoW or WSJF. And it is one case, one author, an unreviewed sheet. I would expect a second reader to push on the "Anti-goal touched?" column, the one with the least evidence behind it.

Where to start

Take the release you are cutting now. Write the point as one sentence that becomes false if the release works, then put your three most tempting cuts through the ledger, one at criterion level. If one makes the point sentence true again, you have found the cut that would have been agreed in a corridor.

The cuts come from the case, sections 1.5, 3.4 and 7. The as-is and to-be template carries the check for what deliberately stayed the same. The context diagram that settles the scope argument handles the boundary itself. And the scorecard has check 12, "Every branch in the to-be where a case waits ends with a named owner and a time limit", which is this case's point written as a check you can run on your own work.

All field notes · The portfolio guide · More in The Case File