The 3 Cs: Card, Conversation, Confirmation

---

Origins

The 3 Cs were articulated by Ron Jeffries in 2001 — one of the simplest and most durable framings to emerge from the Extreme Programming community.¹ XP teams had been writing user stories on index cards for years, and Jeffries wanted to clarify what those cards actually represented. The answer, he argued, was not the requirement itself, but a memory aid for a conversation that would produce the requirement.

The 3 Cs — Card, Conversation, Confirmation — captured this in a single mnemonic. Twenty years later, it remains the cleanest antidote to the slow drift of stories back toward specifications.

Card

The card is the artifact. Originally, a literal 3x5 index card. Today, a row in Jira or a sticky on a board. What matters is its constraint: a card is small. There is not room for everything. The card holds just enough to remind the team what the story is about and who cares about it.

The canonical card format — “As a <role>, I want <capability>, so that <benefit>” — was Mike Cohn’s contribution, not Jeffries’.² It is useful but not sacred. The card’s job is to be a placeholder, not a contract.

Conversation

The conversation is where the actual requirement lives. The card triggers a discussion among developers, the product owner, designers, and (where possible) the user, in which the details get worked out. This is when ambiguity surfaces, edge cases get raised, and trade-offs become explicit.

The crucial move in the 3 Cs is to refuse to write the conversation down in advance. The temptation is enormous: write detailed acceptance criteria, attach a spec document, paste in mockups, embed links to wireframes. Every one of those acts shifts the story back toward being a specification — and the people who would have had the conversation now read the doc and skip it.

This is not an argument against documentation. It is an argument about when documentation happens. Useful artifacts emerge from the conversation; they do not precede it.

Confirmation

The confirmation is how the team knows the story is done. In modern practice this usually takes the form of acceptance criteria or executable tests — concrete, observable conditions that the working software must satisfy.

What separates confirmation from up-front specification is timing and provenance: confirmation criteria emerge from the conversation, captured by the people who were in it, just before development begins. They are short, behavioral, and grounded in real examples — not exhaustive requirement lists written in isolation.

See Acceptance Criteria vs. Acceptance Tests for the deeper treatment of how confirmation gets expressed.

Why the 3 Cs Still Matter

The 3 Cs feel quaint until you watch a team without them. The pattern is unmistakable: a Product Owner writes detailed stories in isolation, drops them into the tool, attaches mockups and acceptance criteria, and expects the team to “just build it.” Stories arrive at planning fully formed and immediately reveal misunderstandings the conversation would have caught. Developers ask questions; the PO defends the spec; trust erodes.

The 3 Cs are a corrective to that pattern. They make explicit what kind of artifact a story is: small, deliberately incomplete, designed to provoke a conversation that produces shared understanding. Done right, the team writes less in the ticketing tool, not more.

The Modern Drift

Jira, Azure DevOps, and similar tools are pulled in the opposite direction from the 3 Cs. They have rich fields, attachment buttons, custom workflows, and acceptance criteria templates. The path of least resistance is to fill them all in. Resisting that drift is a deliberate act — and one of the small disciplines that distinguishes a healthy backlog from a documentation graveyard.

Coaching Tips

Watch where details accumulate.

If acceptance criteria are being written by the PO alone, the conversation isn't happening — the card has become the spec.

Time-box refinement deliberately.

A short, focused conversation is more useful than an exhaustive one. Leave some ambiguity for development to surface.

Capture only the confirmation.

After refinement, write down what the team agreed would prove the story done — not a transcript of the discussion.

Keep cards short.

If the card has six attachments and twelve bullets, it has stopped being a card. Move details to a linked document or — better — back into a conversation.

Resist the "send it over" handoff.

Stories that arrive in planning without a prior conversation will be rejected at planning — better to catch it in refinement.

Teach new POs the 3 Cs first.

It's the single most leveraged framing for someone moving from BA culture to agile product work.

Summary

The 3 Cs are a small idea with outsized consequences. They reframe a story as a working medium between people rather than a contract between roles. Teams that internalize this end up with shorter cards, richer conversations, and more accurate confirmations — and a backlog that documents intent rather than dictating implementation.

Back to Story Crafting