Card, conversation, and confirmation is a formula created by Extreme Programming (XP) co-founder Ron Jefferies in 2001. It was designed to distinguish user stories from use cases and offers a quick and easy way to produce user stories that are easy to understand.
The 3 C’s framework covers the entire life-cycle of a user story to ensure full clarity throughout the team.
Card, conversation, and confirmation — also known as The 3 C’s of user stories — is a simple framework that helps to remove the jargon or fluff from user stories. The idea is to produce something that is clear enough that it can be understood by anyone, including developers, stakeholders, and customers.
Card - A card or sticky note is used to give a physical manifestation of the user story. This helps to cement the requirements in the team’s heads as there is a physical representation, rather than a hypothetical idea.
Conversation - This refers to the second stage of working with user stories: how to achieve the card’s requirement. Teams will discuss, ideate, and ask questions to develop a shared understanding of the situation, as well as potential solutions.
Confirmation - The final C refers to the process of solidifying plans to move forward. The team will use decision-making frameworks to figure out the optimal solution, taken from the Conversation stage to solve the requirements from the Card stage.
The 3 C’s framework covers the end-to-end process of a user story. The card offers a visualization of a real user pain point, which triggers deep, meaningful conversation about how to solve that issue. The final confirmation stage ensures that no user story goes unanswered and teams aren’t moving onto other tasks, leaving the user story unfinished.
User stories should incorporate agile principles, including:
The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Working software is the primary measure of progress.
Capturing user stories on cards is a great way to incorporate the 3 C’s into your agile working environment. As with other agile ways of tracking progress, cards can be easily moved around to clearly indicate priorities. Agile user stories are prioritized and visualized with cards to ensure the entire team is aligned with the current goals.
It’s important to make sure that user stories are not confused with specifications or tasks, especially in an Agile setting. Agile projects use an iterative process — creating products using small, incremental steps. These steps are represented as tasks in the product backlog, and those tasks are often visualized using cards, like we use for user stories.
The key difference is that user stories are exactly that: a story that we tell and discuss with our teams to find a solution to the problem that the story represents. This is the conversation stage. This stage can be performed like you would any other Agile event where the purpose is to come up with a solution to a customer pain point, with a clear set of metrics to help teams know the user story has been completed.
A user story cannot be considered solved until the team can confirm that it has been completed. The final C, confirmation, is designed to make sure that user stories are fully completed before the team moves on and forgets about it.
In Agile, the Product Owner is responsible for checking that the work performed accurately addresses the needs defined in the user story. They will test the product and check against the criteria that was specified during the conversation stage.