A Comment Cannot Block a Story

The proposal was to stop raising QA findings as tracked issues and drop them as comments on the parent story instead.

Half of that is a good idea. The other half deletes evidence, and it does it without anyone noticing.

What the Proposal Gets Right

Not everything QA produces is a defect.

A large share of it is conversation. An observation about a rule that seems inconsistent with a neighbouring one. A question about whether a behaviour is intended. A note that the design says one thing and the demo showed another. That material belongs next to the story, in a thread, where the analyst and the developer and the tester can read it in sequence and reach an answer in three replies.

Filing all of that as tracked issues does produce a board full of things that are not defects, and a board like that stops being read. The instinct behind the proposal is sound.

The trouble is that it treats one property of QA output — that some of it is discussion — as if it were the only property.

The Four Things a Comment Does Not Have

Put a finding in a comment and you give up four mechanisms at once.

It has no status. Nobody can tell open from answered without reading the whole thread and forming a private opinion about it.

It has no owner. A comment is addressed to everyone, which in practice means it is addressed to nobody in particular, and the person who could answer it is not aware they have been asked.

It has no resolution. There is no moment where it becomes done. It just stops being replied to.

And critically: it cannot block anything. A comment sits alongside the story's workflow rather than inside it. The story moves to done with the comment still on it, and the comment goes wherever closed stories go.

The Question That Left With the Story

Here is the concrete one that made this real for me.

Is it intended that a product with no configured limit auto-approves any discount amount, all the way down to zero, with no manager involved?

That is not a defect. There is nothing to fix until somebody in the business says which behaviour they wanted. It is a genuine open design question, and it is exactly the kind of thing a comment thread is supposedly good at.

As a comment, it rides along on the story. The story gets tested, the story gets accepted, the story closes — and the question leaves with it, unanswered.

That is the part worth sitting with. An unanswered design question that dies on story closure is not a lost comment. It is a design decision, made by silence, and the de-facto answer is always "yes, as built."

Nobody made that decision. Nobody would defend it if asked. It is now in production.

The Second Loss Is Slower

There is a further cost that shows up a sprint or two later.

Comments cannot be counted, filtered or categorised. They do not appear in a query, they do not carry a type, and they cannot be pulled into a report.

So when the team sits down to do escape analysis — what got through, what class of gap produced it, where should the net move — the findings that lived as comments are not in the dataset. They did not become part of the record that the next cycle learns from. The analysis is run on the subset of QA output that happened to be filed the older way, and it concludes that the process is healthier than it is.

You lose the finding once when the story closes. You lose it a second time when the team tries to learn from the period it belonged to.

Two Kinds of Output, Two Routes

The rule I would apply is a split, not a preference. QA produces two things, and they need different carriers.

• Route defects to the board, always. A developer works from a queue of issues, not from a comment thread on a story they have already stopped looking at. A defect has an owner, a status and a lifecycle for good reasons, and none of those reasons weaken because the defect was found before release rather than after it.
• Give every open question a trackable carrier as well as a conversation. Let the discussion live in the comment thread — that is genuinely where it works best — but create a linked clarification item that blocks the story. The thread holds the reasoning. The linked item holds the fact that an answer is still owed.

The second point is the one that gets resisted, and the resistance is usually framed as overhead. It is worth naming what the overhead buys: a question that cannot leave the room without somebody deciding it.

The Cheaper Version of the Same Guarantee

If a linked blocking item is too heavy for your team, there is a lighter mechanism that produces most of the same effect: a definition-of-done gate.

No story closes with open clarifications on it.

That single line puts the burden where it belongs. Closing a story now requires somebody to look at what is outstanding and either answer it, or accept it explicitly, or move it into a new item that survives the closure. All three outcomes are fine. The one outcome the gate removes is the silent one.

Why This Gap Is Expensive Rather Than Annoying

Open design questions are not low-severity findings. They are the class of gap most likely to resurface after go-live, in the most expensive place, because they concern intended behaviour rather than broken behaviour.

Broken behaviour gets caught by tests. Somebody wrote an assertion, the assertion fails, the mechanism works.

Unintended-but-working behaviour has no assertion, because nobody knew which way it was supposed to go. It passes every test in the suite and reaches production intact, and the first person to notice that the rule is wrong is a customer or a support agent.

The question that dies in a comment thread does not become nothing. It becomes a decision.

In your process today, what physically stops a story closing with an unanswered question on it?