User Stories
The 3 C’s
User stories were developed as an alternative to traditional requirements, focusing on the individual problems that are constituent parts of the wider problem that a software solution is being developed to tackle.
They emerged from software engineering to provide an outline of a specific problem to be solved, and they represent the work to solve individual, granular problems.
They're not the same as requirements, as they don't specify a software feature, but the work they represent results in one or more software features (or even sub-features) being developed.
The three C's were first described by Ron Jeffries in 2001 and provide an easy to remember description of what user stories are, how they should be written and used. The three C's of user stories are Card, Conversation and Confirmation.
Card
User stories are usually written on a card. The cards can be physical or virtual. Often, if teams use physical cards they might just use index cards or even post-it notes.
User stories can be written in virtual cards when teams use tools like Trello, Jira or Azure Devops to help them manage their work.
Users stories are often written in a specific way to encourage the delivery team to think about the user and the problem that the user has. This helps the delivery team understand why the solution is important to the user and to develop the best solution for them. (Unlike traditional requirements that tend to specify the solution without describing the problem.)
A typical format of a user story is:
As a type of user,
I want what the user wants to achieve,
So that the problem description (i.e. why it's important to the user).
For example, if someone has a medical condition that they have to get treated at a hospital, and they have other things in their lives that are just as important to them, then they might want to be able to choose a time for their hospital appointment to ensure it doesn't clash with anything else they've arranged. You could write a user story which describes this as follows:
As a patient,
I want to choose the time of my hospital appointment,
So that I can make sure that it doesn't clash with anything else I need to attend.
Conversation
The second C is conversation. Probably the most important of the three C's.
User stories are a placeholder, a reminder for the delivery team to speak with users to understand their needs, and with each other to determine the best solution.
Conversations occur at different times during the lifecycle of delivery, and their purpose shifts from understanding the problem, to gaining clarity to come up with design ideas for possible solutions, to seeking feedback on potential solutions, and verification that the solution meets the users needs.
Sometimes the conversations take place as part of planned, facilitated events. Other times they can occur in an off-the-cuff, ad-hoc manner. In either case conversations should be encouraged not only to gain a common understanding about the problem and solution, but also because conversations help to build relationships, a sense of team and collaboration, and make it easier to have further conversations in future.
User stories provide that focal point for conversations - they enable exploration of the problem at different levels of detail during the delivery lifecycle.
Confirmation
The final C stands for confirmation and is about describing ways in which the solution can be checked to ensure that it solves the problem described by the user story.
These checks are often described as acceptance criteria, and are usually written on the same card as the user story. On physical cards they are often written on the back of the card, and in online tools there is usually a section where they are recorded with the user story or are added at the end of the description. Sometimes if a team has automated testing tools, the acceptance criteria are written in a way that allows the checks to be run as automated tests once the solution has been built.
They should be written as short, distinct checks that can be carried out against the solution. It should be easy to determine whether the solution passes or fails each of the checks.
Acceptance criteria are determined through conversations with users and should be defined before work to develop the solution commences.
User Stories Applied for agile software development by Mike Cohn, is an excellent book that covers all aspects of user stories, with lots of useful practical information.
