3 C’s of User Stories- Well Explained

People who work in an Agile environment know the significance of user stories. Agile methodologies put people over processes and carry forward their projects in a way that anyone associated with it gets a complete understanding. That is why writing user stories under Agile is emphasized.

There is a responsibility to generate the user stories so efficiently that even the most unversed person gets the entire idea by merely going through it. These stories give an overview of each product's features and tell the details behind every part of the project. It is a step-by-step process where the requirements get gathered on cards, brought to discussion through conversation, and go into the confirmation stage once everything gets sorted.

Let us dig deeper and discuss user stories and the 3 Cs of user stories in detail.

What is a User Story?

In simple words, a user story is an informal document that briefly explains the software system. You use an end-user perspective to write this document, ensuring all the requirements and expectations from the product are clear to everyone associated. In the user stories, there is a short yet clear explanation of every feature or functionality of a software product. Anyone getting involved in the project in any manner at any point in the process can refer to the user story and get a complete idea about the entire product. It is significant to note here that user stories vary from use cases. These are to address the priorities and understand the current state of the product.

How Do You Define a User Story?

A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer—Atlassian

Writing requirements may be easy for those developing the project. But what about customers, who may not always understand technical jargon? Scrum, with its emphasis on customer collaboration, solves this problem with the help of user stories.  

Scrum involves breaking down a complex project into smaller chunks. Each chunk, called an epic, is further broken down into smaller units called user stories. A user story, thus, is the smallest unit of work in an agile project. It describes the end goal to be achieved and is always told from the perspective of the user. In other words, user stories are the foundation or the building blocks of larger units within the project—like epics and initiatives. let's understand the process of 5 whys root cause analysis here to identify the main reason for the problem.  

Since it is told from the perspective of the user, it is written in a form that is easily understood by the user. This means, it is written in a simple and informal way and explains what the software feature it represents is supposed to achieve. It is not detailed, rather it is short and not more than a few sentences long. If needed, requirements may be added to the user story as more get chalked out during the course of the development of the feature in the sprint.  

So, in other words, a user story describes one specific need or requirement of the user. It may also be called as a scenario. Use stories can be written on index cards, word documents, or even on excel spreadsheets. 

User stories are also great for estimating the work to be done or the work left to be done. The estimation of the amount of work to be done or the effort required to complete the work is necessary as this will help in determining the schedule, costs, and resources required to deliver the requirement. As a manager, taking a PMP certification course will give you the opportunity to master user stories while you are working.

Some of the methods of estimating using user stories include: 

• Planning Poker 
• T-shirt sizing 
• The Bucket system 
• Affinity mapping 
• Ordering Method, and more

When Did User Stories Originate?

User Stories are chunks of the desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes--– Martin Fowler  

So, the question here is, when did we first actually start using user stories? According to Agile Alliance®, user stories first originated in 1989 in Extreme programming, an agile software development framework like Scrum. While originally, at the time of their introduction they were very similar to use cases, over time their detail and scope changed. 

User stories and use cases may still sound and look very similar, but there are subtle differences between the two. A user story is more about the need or requirement of the user while the use case describes the feature that we build to fit the needs described by the customer. They are a bit more technical and define the interaction of the feature being built with the rest of the system, software or process.  User stories on the other hand are easier to read and understand.  

According to Ron Jeffris, who proposed the Card. Conversation, Confirmation model for user stories, use cases are documentary requirement practices while user stories are social requirement practices.

Three Cs of User Stories - Well Explained

“Card, Conversation, Confirmation”; this formula (from Ron Jeffries) Captures the components of a User Story—Agile Alliance 

In 2001, the Card, Conversation, Confirmation model for user stories was proposed by Ron Jeffris for extreme programming, where he states user stories to be critical elements of the XP “Circle of Life”. Let’s look at the three aspects of user stories.

1. Card

Where are user stories written? On cards. They are written manually on index cards and this exercise helps keep the user stories concise. The card will not contain all or too much information on the requirement. Instead, the card will have only enough information to identify the requirement and help everyone understand what the story is.  

The card represents the requirement and is a great tool for planning. It can also be used to write down some more notes like the priority or the story and the cost involved. The Product Owner, after finalizing the user story to be picked up for the particular sprint, will hand over the user story card to the developers.  

The standard format used for writing the user story on the card is as follows: 

As a [user type], I want / need [goal] so that I can accomplish [justification/business value].

2. Conversation

The card is the first step toward formulating the user story, but the requirement needs to be further discussed and refined, and communicated to the developers. This is done through conversation. The conversation between developers, Product Owners, Scrum Master, and the stakeholders also fosters collaboration between all, thus helping in getting a shared understanding of the requirement and leading to the development of the product.  

This exchange of thoughts and opinions through conversation takes place incrementally over time, starting from story estimation carried out during release planning and then during the sprint planning meeting when the story is picked up for implementation. While the conversations are mostly verbal, documents can be used for support.

3. Confirmation

Even with the most in-depth conversation, there is always an element of doubt about the requirement that has to be created. How do we proceed with the user story and ensure that this is what the requirement states? 

This is done through the third C of the user story— ‘confirmation’. Confirmation is in the form of acceptance tests. The confirmation is the acceptance criteria that captures the essential requirements and helps us test the created product to ensure that it meets the defined criteria.  

Acceptance criteria are generally created by the Product Owner and further refined and extended in the backlog refinement. The developers implement the acceptance criteria or acceptance tests. The increment created based on the user story should satisfy the acceptance tests, which confirms that the feature has been implemented correctly. The developers, at the end of the iteration, demonstrate the completion of the story by passing the acceptance criteria. This is confirmation completed. 

When these three Cs of the user stories are completed and satisfied, the feature created is compete and can be released. 

Top Cities where Knowledgehut Conduct Project Management Certification Training Course Online

Project Management Courses in London	Project Management Courses in Singapore
Project Management Courses in Melbourne	Project Management Courses in Toronto
Project Management Courses in Sydney	Project Management Courses in Perth
Project Management Courses in Bangalore	Project Management Courses in Dubai
Project Management Courses in Mumbai	Project Management Courses in Brisbane

User Story Template: The Role, the Action, and the Benefit

Unleash your potential with Agile Management! Obtain agile certificate online and guide your team towards success with adaptable and effective strategies.

A user story template defines the format that is used while writing user stories. According to Agile Alliance the most common template uses the format, “As a… I want to… So that…” 

• As a (who wants to accomplish something) 
• I want to (what they want to accomplish) 
• So that (why they want to accomplish that thing) 

A user story is written from the point of view of the user. It describes the role of the user, the action or what the user needs and the why of the story or the benefit that it provides.  

Let’s look at each of these components in detail: 

• The role: The role refers to the user who uses the system or for who the feature is being built. The developers are not the users of the feature. 
• The action: The ‘what’ part of the story suggests the action or the behavior of the system. Each story has a unique action.  
• The benefit: This is the result of the action, which is what the user needs to happen. 

Examples: 

As <a user> I want to be able to <search> so that <I can get the products I want> 

As <a user> I want to able to <add items to cart> so that <I can check out the items> 

Delve into the most popular KnowledgeHut's Project Management Courses

PMP Certification Training	Prince2 Certification Training	PMI-CAPM Certification
PgMP Certification Training	Prince2 Foundation Certification	Project Management Masters Program
Prince2 Agile Certification	PMI-RMP Certification Training	Prince2 Practitioner Certification

How to Write a Good User Story with INVEST

INVEST is an acronym for: 

• Independent 
• Negotiable 
• Valuable 
• Estimable 
• Small 
• Testable 

A good user story should encompass all these properties. Let’s examine each of these features: 

• Independent: Keeping stories independent of each other helps to prioritize stories on the backlog. If a story is dependent on other stories, then it cannot be taken up till the other stories are completed, even it has a higher priority.   
• Negotiable: A story is negotiable which means that it can be altered based on the conversation that happens between the developers, Product Owners and consumers. A collaborative dialogue between the developers and the users for whom the feature is being developed, or the user’s proxy, that is the Product Owner, is a must. All parties must arrive at a common vision and then development must start.  
• Valuable: The user story must be measurable, which means that it must add value to the overall project. So, a user story must add value not just to the user for who it is being developed but it should also satisfy non-functional requirements.   
• Estimable: A user story must be estimable so that its value and subsequent priority can be gauged. This helps the product owner decide its priority in the product backlog.  
• Small: User stories represent the smallest unit of work in Scrum projects and represent a small functionality that the product delivers. If the user stories are large, they must be broken down into smaller units as smaller user units help in faster delivery of the features. 
• Testable: Every user story needs to be testable to confirm that it is working as it should and delivering value to the customer. The acceptance criteria are written for this purpose. When the user story passes the acceptance criteria it is complete and ready to be shipped.  

Tips for creating great user stories

Roman Pichler has come up with these tips that will help create fail-safe user stories: 

• Write the user story from the point of view of the user 
• Use personas to create the best user story scenario 
• Ensure collaboration while creating a user story 
• Keep stories simple 
• Start with epics 
• Keep refining the stories till they are ready 
• Add acceptance criteria 
• Use paper/index cards for writing down user stories 
• Make sure your stories are visible and accessible 

Conclusion

User stories are a significant technique in the Agile methodology that provides context to the developers before the project starts. This document forces the team to think critically and address issues that the customer might face. Writing the user story is a significant part, so it is crucial that everything gets done in a sorted manner. It helps prioritise each task by explaining the confirmed user requirements and giving a way to the development team.
Hence, the development team or anybody writing them should have clear information about the 3 Cs of user stories and how to write an efficient user story. There are Agile certifications that one can complete to learn various methodologies along with learning to write user stories. Understand that the more efficient and self-explanatory your user stories, the better the product delivery.