Nobody Announces a Descope. They Just Cross It Out.

One line in the acceptance criteria had a line through it.

The criterion said the cart should show the monthly cost that applies once the discounted months end. Reasonable behaviour, clearly written, and now crossed out inside the story body. No comment underneath. No separate marker. No note explaining who decided or when.

The story otherwise looked exactly as it had before.

Descoping Happens in Place, and In Place Is Invisible

That formatting is not sloppiness. It is the most natural thing in the world to do.

Somebody decided the criterion was out. They opened the story, struck the line rather than deleting it — deliberately, so the history of the decision stays readable — and saved. From the author's point of view this is careful work. The line is preserved, the intent is legible, nothing was destroyed.

From every downstream reader's point of view it is silent.

The ticket title does not change. The status does not change. The notification, if anyone gets one, says the description was updated, which is the least informative sentence in the tool. Anybody who read the story last week has no reason to read it again, and rereading a story you have already analysed is one of the least appealing tasks in the job.

So the change is present, permanently, in a document that everyone believes they have already read.

The Cost Is Carried by Test Cases That Still Exist

Deleting a criterion does not delete the work that was built on it.

Test cases written against that criterion do not know they have been orphaned. They sit in the suite, correctly formatted, referencing a real story, asserting behaviour that will now never be built. Nothing in the tooling connects an edit in a story body to a row in a test management system.

Then the build arrives and the case fails — legitimately, by its own terms. The cart does not show the post-discount monthly cost, exactly as decided.

What happens next is the expensive bit. The failure gets treated as a defect, because it looks precisely like one: a documented expected result, an observed behaviour that contradicts it, evidence attached. The report goes to a developer who implemented the story correctly. Somebody eventually finds the struck-out line, and the whole exchange resolves into nothing, having consumed a triage, a developer's afternoon and a small amount of the tester's credibility.

A defect raised against a decision is worse than no defect at all. It teaches everyone around it to trust the next report slightly less.

The Same Formatting Means the Opposite Thing Elsewhere

There is a second kind of strikethrough, and confusing the two is easy.

On another story in the same family, a list of triggers enumerated which changes cause contractual documents to be issued. Changing the broadband discount was on the list. Adding a fixed-IP add-on was on the list too, struck through.

That strikethrough is not a descope. It is an oracle. It records a decision about system behaviour — this change does not trigger documents — and it hands over a negative test case for free, which is the hardest kind of expected result to establish on your own.

So the formatting carries two entirely different meanings and the tool gives you no way to tell them apart. The distinction is structural, and once you see it it is obvious:

A struck line that is an acceptance criterion removes work. A struck line inside an enumeration of conditions defines behaviour.

One tells you a test case must go. The other tells you a test case must exist.

What to Do the Moment You See One

Treat any strikethrough in a story as an event, not as formatting. It costs a few minutes and it happens rarely.

• Establish which kind it is before anything else. Criterion or list item. If you cannot tell from the structure, ask in the ticket — and ask in the ticket rather than in chat, so the answer lands where the next reader will find it.
• Re-read the whole story, not just the struck line. An in-place edit is evidence that someone reopened this story and made a decision. Decisions rarely arrive alone, and the other changes came with no formatting at all.
• Audit your existing cases against the new scope and record the outcome. Which cases just became wrong, which became unverifiable, which are unaffected. Write the reason next to the ones you retire, because a case removed without an explanation gets proposed again next sprint by someone who spots the same gap.

The third point is the one that pays. An orphaned test case that is deleted silently is indistinguishable from coverage that was never written.

Why It Escapes Every Time

Retesting is done against the ticket as it is understood, not against the ticket as it now reads. That is not laziness — it is the only economically sensible way to work, because rereading everything before every retest would consume the entire test window.

The result is a systematic blind spot around in-place edits. The information is available to everyone and read by no one, and the story looks identical whether or not it contains a decision that invalidates half your suite.

Which means the only reliable defence is the habit: strikethrough seen, story reread, cases checked. Small, mechanical, and roughly the same cost as one false defect report a quarter.

When a story is edited after your test cases are written, who tells you — and what happens if nobody does?