One Queue, Two Names, One Story

Two acceptance criteria. One destination queue. Two names for it.

Nobody wrote a wrong requirement. That is what makes this one worth writing down.

The Story That Named the Same Thing Twice

A case management story for a voice porting process. Cases route to a queue, and the queue is the whole point of the story — get it wrong and the work lands in front of people who cannot action it.

One acceptance criterion named that queue in full words. Another acceptance criterion, in the same story, used a short internal acronym.

Read one line: correct. Read the other line: correct. Read them together and a question appears that neither line answers on its own — is that the same queue, or two?

Why the Review Did Not Catch It

Acceptance criteria are reviewed the way they are written. Line by line, top to bottom, each one checked for whether it is testable and whether it says something true.

Both lines passed that check. Individually they were fine. The defect did not live in either line — it lived in the relationship between them, and a line-by-line pass has no step where relationships get examined.

The supporting Confluence page then copied the same ambiguity forward instead of resolving it. That is the part that should make you uncomfortable. A second artefact restated the problem, and because the same two names now appeared in two places, they read as settled. Repetition looks like confirmation. It was propagation.

The Moment It Stopped Being a Documentation Problem

A developer cannot build "either of two queues."

At the point of implementation somebody has to pick one, and there is no mechanism in the process that makes them announce the pick. They read the story, they resolve the ambiguity privately, and they build. The build is internally consistent. It just encodes one of the two readings.

Then QA tested the other reading, because QA read the other line first.

The result was a Highest-priority defect against a story whose requirements nobody had written incorrectly. Ambiguity in a document costs nothing until the moment someone downstream is forced to choose. Then it costs a full defect cycle: raise, triage, prioritise, fix, retest.

What This Was Not

It was not a missing requirement. Both readings were specified.

It was not a careless developer. Picking one of two plausible names is what implementation is.

And it was not a tester who tested the wrong thing. The tester tested exactly what an acceptance criterion said. That is the trap in this class of bug — everybody involved did their job against the artefact in front of them, and the artefact disagreed with itself.

The tester who never sees it is the one who tests acceptance criteria the way they are numbered: AC1, then AC2, then AC3, one at a time, each in its own run. Testing in that order is efficient and it guarantees the two lines never sit side by side.

The Check That Would Have Found It in a Minute

Read the story twice. The second time, read it vertically.

• Extract every named entity in the story into one list. Queues, record types, status values, profiles, field labels, email templates, anything that is a proper noun in the system. Take the exact string, not what you think it means.
• Treat every distinct string as a distinct entity until proven otherwise. A full name and an acronym are two entries on that list, not one. So are two spellings, two capitalisations, and a name with and without a suffix. Proving they are the same is a question you ask someone — it is not something you conclude by yourself, because concluding it by yourself is exactly what the developer did.

That is a five-minute pass over a story, and it happens before an environment exists, before test data exists, before anyone has spent a cycle.

Naming drift between acceptance criteria is a documentation bug for as long as it stays on paper. It converts into a real one the instant a developer has to take a side — and the conversion is silent, because nothing anywhere logs the moment somebody chose.

In the story you are testing next, how many named entities appear in more than one acceptance criterion — and have you checked they are spelled the same way?