Those of you who work in an Agile environment must know that it has many values attached to it. And an important one of them is people before processes. Developers can quickly write the requirement, but the customers, who may be new, may find it challenging to understand the technical language. But when the emphasis is on collaboration with the customers, this problem is solved through User Stories. A project is split into several small parts called Epics, which are further broken into smaller units, and these units are called User Stories. So, the smallest part of any Agile project is the User Story. This article will present and discuss the 3 C's of User Stories. But before moving on to that, let's describe the User Stories in detail.
What is a User Story?
Simply told, a User Story is a brief, simple, and precise description of a specific feature written by a Developer from the customer's viewpoint. The purpose of a User Story is to express how the customer will get value from the particular feature. So, we can say that it explains the ultimate objective desired to be achieved from the customer's perspective. The description includes what kind of customer it is for, what they need, and why. Thus, the requirement is told more straightforwardly. As the User Story is written from the customer or user's viewpoint, it is written in such an informal and straightforward way that the user does not have any difficulty understanding it. The best part of a User Story is that the end product may be very complex. Still, the User Story is articulated so explicitly that even a non-specialist can understand it. This becomes the basis for a product that fulfills the customer's requirements is developed. When a set of User Stories is introduced, it becomes a part of the discovery process. However, User Stories are continuously added all throughout the Agile delivery process. Writing User Stories is a good way of encapsulating the user requirements with a focus on their goals. It's a way of determining the value the feature will bring to the customer.
Whether you are new to Agile or have been using User Stories for some time, if you know about User Stories, you must also know about the 3 C's of User Stories. Writing an efficacious but simple User Story may be challenging, although it may look easy on the surface. This is where the 3 C's of User Story come in handy. These 3 C's are Cards, Conversation, and Confirmation. These are essential components for writing a good User Story. The Card, Conversation, and Confirmation model was introduced by Ron Jefferies in 2001 for Extreme Programming (XP) and is suitable even today. So, let us examine these 3 C's for writing User Stories.
3 C's of a User Story
Cards
Cards are where User Stories are written. A card forms the basis for a conversation. When a card is placed on the board, the team is committed to discussing that specific user requirement. The cards are usually 3 inches by 5 inches. Before, cards used to be written manually, but nowadays, physical cards are not always used, and many people use digital cards to write User Stories. The User Story written on the card should precisely reflect the customer's need. It need not contain all the detailed information, just enough to describe the user requirement. The cards can be post-in cards, index cards, or electronic or digital cards. The card type is not essential; what matters is what is written on it. Writing the User Stories on cards helps keep them short but enables all concerned to know what the story is about. It is a beneficial tool for planning also. The standard format used for writing the User Stories on the cards is: As a (particular user), I want to (accomplish this task) so that I can (achieve this objective or goal). The card can also include more information like the story's priority and the cost involved. The User Stories collected on the cards make the product backlog. But even if all User Stories on the cards are not fully formed, we can still make progress. You can develop the most critical features and leave the less essential functionalities later. There are some other benefits of cards too. First, they can be shifted around, reflecting the priorities. So, it becomes straightforward for everyone to visualize priorities. To add to it, if new information is received, these priorities can be changed by moving the cards around. Once the Product Owner finalizes the User Story for a particular Sprint, they hand the card to the Developer.
Conversation
The card is the starting point of constructing a User Story. It depicts the customer requirements, but these requirements should be discussed further and, if needed, refined and given to the Developers. As we said earlier, when a User Story is written on a card and put on the board, it reflects the commitment of the team to discuss the User Story. This is important for discovering how best the business value can be delivered. The conversation is the way to achieve this. The User Story describes a need that must be fulfilled; it does not provide specifications. So, when the team holds a conversation on the User Story, it changes into a deliverable. It is nothing but a phased exchange of ideas and viewpoints which takes place over some time. The conversation also helps bring clarity about the User Story to the team members as sometimes it may be hard to interpret. It also lets the Product Owner provide information to the team about the goings on so the team members grasp the information accordingly.
Initial user research and brainstorming can be a part of the conversation. The conversation should be interpreted as collaboration. When starting to work on a User Story, the team should thoroughly discuss the story, from understanding the customer's requirement to what needs to be delivered. During the conversation, the User Story is further expanded and validated. Conversations can be of any type like verbal, through emails, videoconferencing, or chatting. The purpose is to exchange views and ideas. But as far as possible, conversations should be a face-to-face affair. Team members should be made to understand how the conversations will aid in generating value for them as well as the users. Conversations do not end once the team starts working on the User Story. As they progress in work, team members would learn more things, and the exchange of views and ideas would continue.
Confirmation
The confirmation is the last of the 3 C's of a User Story. The confirmation is the Acceptance Criteria that should be fulfilled and tested to ensure that the user requirements have been met and delivered correctly. These Acceptance Criteria are discussed during the conversation. Acceptance Criteria should be clearly stated before starting the development. This is necessary to avoid any ambiguity about the completion once the User Story has been completed. These Acceptance Criteria provide the basis for acceptance tests that would determine the acceptability of a product. The team may have held a deep conversation regarding the User Story, but even then, there remains an element of doubt if the user requirements have been clearly understood. So, confirmation makes sure that the criteria have been entirely met. The Product Owner should test the functionality and confirm that it meets the customer requirements described in the User Story. At the end of an iteration, the completion of the User Story is confirmed when it passes the acceptance tests.
The teams should not write too many Acceptance Criteria as they will encounter changes in requirements during their work, and accordingly, the descriptions will also change. Too many Acceptance Criteria may bring them too much rework.
The functionality is considered complete and ready for release when these 3 C's of the User Story are completed.
Writing a User Story is easy but writing a good User Story is an art in itself. An excellent understanding of user needs is required. These 3 Cs work from the beginning to the end of a User Story. It starts with writing the User Story on the card, which necessitates holding the conversation through which the story is refined and understood more clearly, and priorities are fixed. Then the development of the feature takes place as per the user requirement. And lastly, the feature is tested on the Acceptance Criteria to determine if it has met the customer's needs or not. Writing a correct and precise User Story is vital for a project's success, and the 3 C's play an essential role in writing such User Stories.
References
- https://chisellabs.com/blog/how-to-write-agile-user-stories-three-cs-examples/
- https://medium.com/analysts-corner/understanding-the-three-c-s-of-agile-user-stories-9d51a86d590c
