Skip to content
Software Architecture Guide

Card, Conversation, Confirmation

Explanation

Section titled “Explanation”

A user story (see the article User Story) is more than a piece of text. It has three parts, often called the three Cs.

Card. The card says briefly what the story is. It can be a literal card, and it needs only a short name. It is a reminder, not a full description. One way to put it: the card is a ticket to a conversation. Many teams write the card with the template “As a [type of user], I want to [do something], so that [reason]”. That template is a thinking tool. Use it when it improves the conversation.

Conversation. The requirement itself passes from customer to programmers through talking, not through a document. The card only points to that talk. The details come out of the dialogue.

Confirmation. As the conversation goes on, the group focuses more and more on concrete examples. These examples become confirmation tests. They can be written as acceptance criteria, examples or tests. Acceptance criteria are details that help the team judge whether the story was completed correctly. See the article Acceptance Criterion.

Agreements are documented by these tests, not by the card. If all the examples pass, the story is done as agreed. This gives everyone a shared view of “done”. The tests exercise the real system. They report whether the expected result occurs.

The model also connects to other story practices:

  • INVEST is a checklist for good stories. Its “Testable” item asks for criteria that measure successful completion. That matches confirmation. See INVEST Criteria.
  • Story splitting breaks a large story into smaller ones that still show meaningful progress. See Story Splitting.

Example

Section titled “Example”

A team keeps a card that reads “Customer resets password”. That is all it says.

The product owner and a developer then talk. They work out what should happen with an unknown email address and what the customer sees afterward.

Those answers become concrete examples, such as “unknown address: show a neutral message”. The team turns the examples into tests. When all the tests pass against the real system, everyone agrees the story is done.

Trade-offs

Section titled “Trade-offs”

The card is short on purpose, so it cannot carry the details. Teams that treat the card as the full requirement lose what the conversation produced. The agreements then live only in people’s heads.

The model also relies on real dialogue with the customer. Without that talk, the card stays a vague reminder.

Writing confirmation examples takes effort. In return, the team gets a clear, shared test for when the story is done.

The three parts of a user story and how they lead to done.

Diagram source 
flowchart LR
  C[Card: brief reminder] --> V[Conversation: work out details]
  V --> F[Confirmation: examples and tests]
  F --> D[Story done as agreed]

Checks

Section titled “Checks”
  • Each story has a brief card or name, and the details are not stuffed into it.
  • Each story has confirmation (acceptance criteria, examples or tests) that tells the team when it is complete.
  • Agreements on a story are documented as confirmation tests, not only on the card.
  • Confirmation tests run against the real system and report whether the expected result occurs.
Section titled “Related”

Sources

Section titled “Sources”