The three Cs of user stories are three criteria that help to ensure that the requirements in your story are clear, complete, and correct. These three criteria are Card, Conversation, and Confirmation.
Ideally, you should include all three elements when writing a user story. If you don’t confirm your requirements they may not be correct (although it’s possible to write incorrect requirements in code).
If you don’t confirm your story with the customer, then it may not be clear or complete enough for them (they may also start to change their mind about what they want at this stage), and if you don’t confirm your understanding of what has been built with the development team then there is potential for misunderstanding between the product owner and the development team, or between developers within the same dev team.
If you consider what three C’s would be needed to make a good story for a three-year-old child, they might be:
Carrot (to give them direction), Conversation (to determine what interests them), and Confirmation (so that they know it is something they can have). They also need a Card – because three-year-olds don’t always remember their tasks!
In XP this is called a confirmation of “done” by the Product Owner after each iteration. In other words, the three Cs of user stories are three stages in an agile software development process.
These three criteria are:
Card: three-year-olds can’t remember their tasks, so parents use picture cards to remind them.
Conversation: three-year-olds need lots of conversations with adults or older children to find out what interests them and how much they already know.
Confirmation: three-year-olds need visual reminders of what they’ve done (“You’ve filled up the fish tank three times now, that’s great!”) or what they’re going to do next (“We’re going to go pick some apples now…”).
The three Cs are used in agile software development for three reasons
1. They help us understand the real needs (and abilities!) of our users;
2. They make sure we build the right thing;
3. They help us plan how to build things right.
When you want to understand what users need your software to do, describe their needs in terms of three Cs: conversations they need to have with people or systems, what they need confirmed by visual or other suitable means of feedback, and which actions will cause an effect that matters to them.
Describing user needs this way helps you learn more about them quickly and makes sure that whatever you build for them is something they will be glad you built!
User Story Examples
Conversation: “As a doctor, I want my patient’s vitals so I can monitor their health.”
Confirmation: “As a doctor, I want to know when my patient’s vitals are elevated so I can inform them of changes in their health”
Action that matters: “As a doctor, I want to warn my patient if their blood pressure or heart rate elevates.”
Example: As a home buyer, I want to search properties for sale by owner so I can save money.
Example: As a homeowner, I want to access my home’s energy usage data to find ways to conserve energy.
As an outdoorsman, I want to be able to find the best hunting grounds near me so that I can hunt more.
The three Cs have been around for years now in various forms, but recently I’ve heard some people criticize them because they tend to produce “finished” stories which sometimes take longer than desired by the Product Owner to complete, or worse… never get done at all!
This criticism is valid, but three Cs are more than just a template. They can be useful even when not all three boxes are filled in perfectly.
As the Product Owner, I want to ensure that written user stories are understood by everyone on the team so that there is no miscommunication about what needs to be built.
For me, three Cs is a great start. It’s better than not having anything at all and it helps the team get started. When we take time to add three Cs, we should be spending that time enhancing them further to make them more user story-like. This will help us improve our backlog. Here are three ways of doing this:
(Stakeholder) As a stakeholder, I want to have a conversation with the Product Owner so I can understand any User Story fully enough so no miscommunication occurs.
Adding three Cs is a noble effort but sometimes there’s just too much context for one person, let alone the whole team, to remember. And if people don’t clearly understand a user story, then the three Cs are pretty much useless. This is basically what Corey Ladas is stating in his three Cs for user stories article.
Label the three Cs with Stakeholder (for example, the Stakeholder wants to be able to do X). If there are multiple stakeholders, put them all on the card. Do not include any other labels; don’t put “Business” or “Developer” or anything else – just “Stakeholder”.
The reason for this is that if you only label three things like this, it simplifies your conversation along those three lines without having to bring up other topics around these three specific points.
Perhaps you would later note scenarios that involve other stakeholder types, but initially just focus on talking about three points using these examples.
