A Layered Story Needs One Line About Which Slice It Delivers
Two Highest-priority defects raised nine minutes apart, both closed as invalid with the same sentence. The story shipped the product catalogue layer; the tester tested the screen and the document, which were correctly empty.
Two defects, raised nine minutes apart. Both at Highest priority.
Both closed as invalid, with the same sentence attached to each: as part of the story, only the product catalogue layer was covered.
Nobody involved was careless. That is what makes this worth writing down.
The Setup
The platform is layered, and the layers build in a fixed order. The product catalogue layer holds the definitions. The guided UI layer renders the configuration screen on top of them. Document generation sits on top of that and produces the contract.
Definitions first, screen second, document third. Each layer consumes the one below it.
The story named a feature. It did not name a layer.
The Symptom
I opened the configuration screen and the new option was not there. Nine minutes later I generated the contract and the corresponding section was empty.
Two findings, both severe by any reasonable reading. A customer-facing screen missing a feature the story said was delivered, and a contract document silently omitting it. Highest priority is not an overreaction to that pair — it is the correct call from the evidence available on the screen.
Both were closed as invalid, correctly.
What Was Actually True
The screen was empty because nothing had been built to render it yet. The contract section was empty because there was nothing on the screen to carry into it.
Both artefacts were correctly empty. Not broken. Not regressed. Working exactly as a system works when the layer below has shipped and the layers above have not.
The story had delivered its slice. The slice was invisible.
Why the Tester Reaches for the Wrong Layer
This is the mechanism, and it is not a discipline problem.
The visible layer is the last one built. It is also the first one a tester reaches for, and for good reasons — it is where the acceptance criteria are written in user language, it is what the demo will show, it is what a customer would notice, and it is the only layer most testers can reach without a developer's help.
So on a layered platform, the tester's natural entry point is structurally the layer least likely to exist yet.
And the arithmetic follows from there. An acceptance criterion that names a feature but delivers a slice of it generates one Highest-priority false defect per invisible layer. Two layers above the delivered one, two invalid defects. Nine minutes apart, because that is how long it takes to check the second thing after the first one surprises you.
The count is not bad luck. It is a function of the depth of the stack and the silence of the acceptance criteria.
What This Was Not
It was not a tester failing to read the story. The story was read. It named the feature, and the feature was not there.
It was not a developer under-delivering. The correct increment shipped, on time, in the correct order for a layered build.
It was not a severity misjudgement either. Given only the screen and the document, Highest was defensible both times. The severity was calibrated against the observation, and the observation was accurate — an empty screen is an empty screen. What was missing was not judgement, it was the one fact that would have reframed the observation.
The One Line
A layered story needs a line in the acceptance criteria stating which layer it delivers and which layers are out of scope until a named later story.
Not "backend only". Not "phase 1". A sentence with two halves and a reference: this story delivers the catalogue definitions; the configuration screen and the contract output are out of scope until story X.
That sentence costs the person writing the story about fifteen seconds. Without it, the tester tests the product instead of the increment, and then gets to explain why two Highest-priority defects were invalid — a conversation that damages the credibility of every future severity call they make.
Which is the real cost here. Not the wasted hour, not the two cancelled tickets. The quiet reweighting that happens next time this tester marks something Highest and somebody remembers the last two.
On your current sprint board, can you tell from the acceptance criteria alone which layer each story actually delivers?