Understanding the three “C”s of agile User Stories (2024)

Whether you’re new to using user stories for software development or have been following this way of writing requirements for a while, it’s always useful to understand the reasons why they are used. I’m not getting into the structure of the words on the card in this article, just the lifecycle of the user stories themselves.

The “three Cs” of User stories is a quick way of remembering the way in which user stories unlock their full potential. Ron Jeffries, one of the founders of the Extreme Programming movement, first suggested the 3 Cs model and it still holds true today.

The three Cs stand for Card, Conversation and Confirmation and in this article, I’m going to discuss each of the elements, explaining why, and how to ensure you’re doing it right. I’ll also scatter in a few tips from my experiences with agile teams. So, let’s talk about user stories…

The first C in the three “Cs” stands for “Card”

A user story card is a placeholder for a conversation. Its presence is a commitment that the team will have a discussion about how to deliver the user need.

User stories are written on cards, these can be post-it notes, index cards or electronic cards in a system like Trello or Jira. What they are written on doesn’t matter, what the concept of cards gives does. The collected user stories form the product backlog, but not all those cards have to have a fully formed user story written on it for progress to be made. The most important items can be developed, with lesser functionality being deferred until later.

For example, let’s take the example of Facebook. The product has been developed over a period of time with new features being added all the time. It is obvious that the ability to share a status and make connections with people form the core of the product with less important functionality, such as notifications and memories being added over time.

By freeing development teams from the need to define everything up front, the product can evolve naturally and as more is learned about the problem domain.

Capturing user stories on cards gives teams a few other benefits.

Cards can be moved around, clearly showing priority. In traditional requirements catalogues, the requirements tended to be grouped by functional area and never moved. On agile projects, user stories are prioritised for development and this is easily represented by cards; importantly the priority can be visualised easily and changed as new information is learned.

For example, when a product is envisaged, the team may think that users will want to be able to change the colour of the screen and the text on it. Over time it may become clear that this is less important than anticipated and can be deferred until later. In fact, a new requirement may emerge from testing with customers, perhaps users need the ability to change the size of the text, that is actually of more value than the original story. The concept of user story cards, encourages the team to slot the new user story in as a higher priority requirement.

As well as being moved around, the concept of user story cards encourages teams to get rid of things that aren’t needed. Taking our screen and text colour example, let’s suppose that our application designers have gone with a mainly pictorial interface; the user story card concept allows us to simply “rip up the card” that we don’t need any more.

The second C stands for “Conversation”

The existence of a user story represents a commitment by the team to discuss the user need and to work to uncover how best to to deliver the business benefit anticipated.

The user story is not a specification for something that must be built but is a statement that there is a need that should be met. Conversation turns the placeholder into something that can be delivered. As such, it may include other elements, such as initial user research, some design work and brainstorming; it might be better to think of the conversation as being “collaboration.”

If you take one message away from this article, it is that user stories are called stories because we should be telling them to each other and discussing the details within our teams.

Agile projects work iteratively, building systems in a series of incremental steps. In Scrum projects, the product owner is responsible for prioritising the backlog and bringing candidate user stories into the team for discussion. Backlog refinement, elaboration or backlog grooming, is the practice of getting ready to build software. This applies across any flavour of agile development whether you’re using Scrum, Kanban, XP or anything else.

As the team begins to work on a user story, they should discuss the user story thoroughly, working from an understanding of the user need through to the solution that will be delivered. Instead of the traditional approach where business analysts and systems analysts would write specifications for their requirements and hand those to the developers, in agile projects the team works together to understand the solution, drawing on the skills of each team member.

When discussing user stories, it is worth remembering the following tips;

• Collaboration is a team sport — some team members will be more comfortable than other getting involved in discussion, but it’s important that they are there to listen to the conversation. You should make sure that it is clear that the entire team should be involved in discussing the work. Avoid the temptation to press on with a small group as they will begin to form a design group.
• Discussing user stories should, wherever possible, be a face to face conversation — attempting to collaborate over user stories in a remote working environment or via email is nowhere as powerful as being in the same room. If you can’t meet in person, use online whiteboarding and videoconferencing to get as close as possible to the in person experience.
• Preparation is valuable time — Some teams and team members can see time spent on user story refinement as time not building software. It is important that the team is encouraged to see that value that they and the end users get from team collaboration.
• Stakeholders can and should be invited — There is a lot of value in getting real end users to talk to development teams, after all, the end users always know more about what they actually need than an intermediary.
• Sometimes you’ll need to discuss user stories a number of times — In my experience, it’s worth having a number of user stories in flight at any one time. Some of these will be vague stories that they team are just beginning to explore, others may be completely ready. It often take a couple of discussions before the team’s understanding has developed enough for them to be ready to cut code.
• The conversation doesn’t stop when the team begins to develop software — One of the most valuable things that agile teams do is learn through doing. Often it’s only by trying to build something that you understand the right way to do go about it.

On a final note, if you’re unable to collaborate with the development team to create your user stories, then you may need to fall back on other techniques, such as developing use cases to create more heavyweight communication artefacts.

The third C stands for “Confirmation”

The user story is not considered finished until it is confirmed as being done. This concept of confirmation stops incomplete work from escaping the development team.

The Product Owner, or their equivalent, should check that the functionality meets the user needs defined in the user story and includes any acceptance criteria that have been agreed during the conversation stage.

As well as the Product Owner’s confirmation, the functionality is tested to ensure that it meets the requirements stated in the user story and any other requirements that apply, such as system-wide non-functional requirements.

In addition to acceptance criteria, in Scrum teams there is often a “definition of done” that works as a completeness checklist. For example, teams I have worked with include items such as ensuring that the user story is marked as completed on the backlog, ensuring that release notes are updated and demoing to other stakeholders. The definition of done is defined by the team as a part of their ways of working.

The three Cs summary

Let’s quickly recap. The three Cs cover the life-cycle of a user story. First the card is created, this creates the need for the next conversation or collaboration stages where the original idea is refined. Assuming that the user story is understood and remains a priority, the team develop the functionality to meet the user need. Finally the team and the product owner, or their equivalent, agrees that the user needs expressed in the user story have been met and confirm that the user story can be marked as “done”.

And, if you follow the basic lifecycle explained above, you’ll not go far wrong on your user story journey!