Main idea

The user story was designed as a promise of discussion: a short sentence, deliberately incomplete, whose function is to bring the right people around the topic. Treated as a contract, it becomes the opposite — a text you execute without talking to its author, and then use to establish who was wrong.

The practical consequence falls on whoever receives the card. A developer shouldn't accept a ticket they don't understand: if elements are missing to assess feasibility, they ask for them; if the business context is missing, they ask for it; if they don't see the value, they say so. That refusal is not an objection on principle, it is the artifact's instructions for use.

Why it matters

This shifts responsibility for a ticket's quality. It doesn't sit entirely with whoever writes it: the card is a starting point, and whoever picks it up has a duty to get it completed.

It also explains why continuously improving templates settles nothing. What an unclear ticket lacks isn't an extra field, it's a conversation that never took place.

Nuances and limits

Not every organization can rely on conversation: a remote team across several time zones, an external supplier, a contractual relationship. Writing there carries a load it was never built to carry, and that has to be owned as a cost, not as a norm.

And a developer who questions every card can also block the flow: asking for clarification assumes you can tell a real gap from discomfort.

Open questions

• What becomes of the requirement for conversation when delivery is contracted out to a third party?