How to Write Good User Stories (Examples and Tips)

What Are User Stories?

User stories are short, simple explanations of a software feature written by someone who desires a new capability. 

User stories articulate how a software feature will provide value to the customer. User stories describe the type of users, what they want, and why. They create a simplified description of a requirement. 

In a product management tool like Chisel, you can record user stories on index cards, post-it notes, or with the influx of SaaS. 

Various stakeholders, such as clients, users, managers, or development team members, can write a user story.

In the agile framework, a user story is the smallest unit of work. It is an end goal, not a feature, expressed from the user’s perspective. An agile user story aims to articulate how a piece of work will deliver a particular value back to the customer. 

“Customers,” in this context, don’t have to be current users in the traditional sense. Instead, they can be internal customers or colleagues within the organization. 

In other words, user stories are a few sentences in simple language that outline the desired outcome. There isn’t much detail, but you add the team’s requirements later once agreed upon. 

A kanban or a scrum is a great way to lay out all potential user stories. In Kanban, teams pull user stories into their backlog and run them through their workflow.

On the other hand, in the scrum, user stories are added to sprints and “burned down” throughout a sprint. 

Think of user stories as the building blocks of larger agile frameworks like epics and initiatives. Epics are large work items broken down into stories, while multiple epics are composed of an initiative.

User stories are typically written by a product owner or a business analyst in collaboration with stakeholders, such as customers, end-users, and development team members. 

The product owner is responsible for creating and maintaining the product backlog, which includes user stories, and ensuring that the team is working on the most valuable features that meet the needs of the users and the business. 

The business analyst works with the product owner and stakeholders to gather requirements and translate them into user stories that are specific, actionable, and testable. 

Development team members may also contribute to creating user stories by providing technical expertise and insight into implementation details. 

Ultimately, the goal of user stories is to capture the needs and expectations of users in a way that is easy to understand and prioritize for the development team.

What Are the 3 C’s in User Stories?

An initial set of user stories is part of the discovery process. The team constantly adds new user stories during agile delivery.

Defining user stories is a convenient way to capture detailed requirements while focusing on user goals. That’s why they can successfully determine the value for your users. 

A good user story consists of three elements called agile three C’s. 

Card

Although you can take this literally, the idea behind the first C – card refers to the user story’s optimal size that can fit on a notecard. 

The card should not contain all information about the requirement. Instead, it must have enough information to plan, identify the need, and remind the team of the overall story. 

This is the format they should follow:

The focus should be on gathering user stories for each user type. It helps create a set of the most representative user stories possible. Ideally, product users should write user stories.

However, it’s okay if other stakeholders or the product owner write them. You can gather user stories through various user research methods such as interviews, questionnaires, observations, and others. 

Using software for product managers like Chisel, user research is easier and more efficient than ever.

Conversations

Before placing user stories in the sprint, the product owner should ask customers for elaboration and validation. 

These conversations are necessary as a user story may be difficult to interpret. Plus, background knowledge could be essential for implementation.

These conversations allow product owners to inform stakeholders of what’s going on. It also allows everyone to digest information accordingly. 

Conversations can include email, internal chat, or any online tool for your cross-functional team. 

Confirmations

The final C of a user story stands for the acceptance criteria. It confirms that the user story has been implemented correctly and is successfully delivered. 

It would be best if you defined acceptance criteria before development begins. It helps determine when each user story is finished and working as intended. 

These criteria demonstrate a user story’s boundaries. They are a common point of discussion during conversations between the product owner, product manager, and users. 

The best practice is to define this criterion before placing user stories in a sprint.

Importance of the 3 C’s in Creating Effective User Stories

The 3 C’s – Card, Conversation, and Confirmation – are essential to creating compelling user stories. They help to ensure that the user story is clear, concise, testable, and accurately reflects the needs of the user and the business.

This, in turn, helps to ensure that the development team is working on the most valuable features and that the end product meets the user and business needs.

Following are the benefits of 3Cs 

1. Clarity: The 3 C’s help to ensure that user stories are clear and concise, which makes it easier for the development team to understand the user’s needs and expectations. This helps reduce misunderstandings and ensure that the end product meets the user’s needs.

2. Collaboration: The 3 C’s promote cooperation between the product owner, stakeholders, and development team members. This helps ensure that everyone is on the same page and that the user story accurately reflects the needs of the user and the business.

3. Consistency: The 3 C’s help to ensure that user stories are consistent in format and content. This can make it easier to manage the product backlog and ensure that the development team is working on the most valuable features.

4. Testability: The 3 C’s help to ensure that user stories are testable and measurable, which makes it easier to determine whether the user story has been successfully implemented and meets the user’s needs.

5. Value: The 3 C’s help to ensure that user stories deliver value to the user and the business. This can increase user satisfaction, improve the product’s competitiveness, and generate more revenue for the company.

Use INVEST To Create Good User Stories

Interested to know what it takes to write a good User story? Let’s first look at the 6 essential indicators of a good user story

INVEST is the acronym you can use to know if you are on track to writing good user stories. 

Independent

Every agile user story must be independent and should stand on its own. It helps in prioritizing, also called user story priority.

Also, you can move them to the product backlog if the agile user story is independent. 

Negotiable

When implementing the agile user story format, there’s a collaboration between teams and customers.

This is where the negotiation comes in. You will have to decide on what to implement and what to skip.  

Valuable

When writing user stories, remember that they must be valuable to the customers. 

Estimable

You must be able to estimate an agile user story.

If a user story is not estimable, then the scope of that story is not well understood. When estimating agile user stories, you can easily distinguish between high and low-effort stories. 

Small

When writing user stories, know that it must take less effort (days or a few weeks) to implement it. 

Any agile user story that is high in the effort is difficult to estimate and negotiate.

Testable

One of the best indicators of writing better user stories is testability. When a customer cannot tell if you have implemented their story, the entire team’s effort may be in vain. 

To avoid this, write the acceptance criteria before implementing the agile user story. 

How To Write Good User Stories?

Now that you know the components of a good user story, let’s move forward! You may know how to write user stories.

But have you ever wondered how to write good user stories? If yes, we will consider how to do so efficiently in no time and even without utilizing paper writing services.

Put Users First

As discussed, a user story describes how a customer employs the product from their perspective. 

You shouldn’t write a user story if you do not know who the users are and why they want this product. 

Do adequate user research first; otherwise, you will risk speculating.

Discover the Right Stories With Personas

Personas are a great technique to capture your insights about the users and customers. 

Essentially, they are fictional characters based on first-hand knowledge of the target group.

They usually include a name, picture, relevant characteristics, behaviors, attitudes, and overall goal. You can understand the goal as a benefit a persona wants to achieve. 

You need to ask, “What functionality should my product provide to meet the personas’ goals?“

Collaborate When Creating Stories

User stories are supposed to be lightweight to allow you to move fast. Think of them as a collaboration tool more than a specification. 

The product owner and the team must discuss these stories together. It will allow you to capture the necessary information, reduce cost, and speed up delivery. 

You can even take this approach and write stories together as part of the backlog grooming process.

That leverages the creativity and knowledge of the team leading to better stories.

Make Sure the Stories Are Simple and Concise

It is ‘the simpler, the better‘ regarding user stories. 

Avoid confusing and overly fluffy terms. Don’t forget to use an active voice. Focus on the essential parts and leave out everything else. 

Roman Pichler created a template based on Rachel Davies’ popular template.

Start With Epics

An epic is typically broken into several user stories over time, ensuring to leverage user feedback in early prototypes.

They’re a placeholder and headline for more detailed stories. Think of it as the scope.  

Starting with epics allows you to sketch the functionality without committing to anything specific. It comes in handy when describing new products and features.

Using it, product managers can capture the rough outline while buying time to learn how to address users’ needs. 

Suppose you have multiple disjointed, detailed stories in the product backlog. In that case, you can have an epic organizing them. Thus, epics make your whole process time-efficient.

Refine Your Stories Until They’re Where They Need To Be

Continue to break your epics into smaller, more detailed stories until they are clear, feasible, and testable.  All developers should have a shared understanding of the story’s meaning while not being too big. 

On top of this, there has to be an effective way to determine if the story is complete. 

Include Acceptance Criteria

As you break down your epics into smaller stories, you must have acceptance criteria.

It will complement the narrative allowing you to describe the conditions you must fulfill to complete the story. 

The criteria will make the story testable and enrich it. You can demo and release it to users and stakeholders. A good rule of thumb is five acceptance criteria for detailed stories. 

Use Paper Cards

Initially, user stories were born from extreme programming Moreover, the literature around it talked about story cards rather than user stories. It is because teams captured the stories on paper cards.

There are three benefits to this: 

• Paper cards are cheap and easy to use.

• It leads to collaboration as everyone can take a card and jot down an idea.

• You can group the cards quickly and cleanly visually.

• If you are in the office, it can have a tangible benefit.

Make Sure Stories Are Visible and Accessible

The central role of stories is to communicate information. Therefore, make them visible. 

Having visibility fosters collaboration and transparency, whether in Chisel or physically on walls. It makes it obvious when there are too many stories. 

Don’t Rely Solely on Stories.

Creating a great user experience is more than just having well-crafted user stories. They capture product functionality but compliment them with other techniques.

These techniques include workflow diagrams, storyboards, mockups, or sketches. Beyond this, they’re not good at capturing technical requirements.

If you need to communicate an architectural element, write a technical story. User stories are great if you want to create a product that is likely to be reused. 

Writing stories may not be necessary if you’re trying to build a prototype quickly.

Remember – user stories enable you to move fast and develop as quickly as possible. 

What Are the Good User Story Examples?

Here are a few examples of well-written user stories:

1. As a customer, I want to save my payment information so that I don’t have to enter it every time I purchase.

2. As a manager, I want to view sales data by region to make informed decisions about where to allocate resources.

3. As a student, I want to track my progress in a course to see which areas I need to focus on.

These user stories are considered good because they meet the criteria of the 3 C’s – Card, Conversation, and Confirmation. Let’s break down each example:

1. Card: This user story is clear and concise, stating the user persona (customer), the action they want to take (save payment information), and the reason for taking that action (to save time entering payment information).

2. Conversation: This user story could lead to a conversation about how sales data should be presented, what regions should be included, and how the manager will access the data. This helps clarify the user’s needs and ensure that the end product meets their expectations.

3. Confirmation: This user story can be confirmed by creating acceptance criteria that define what it means for a student to be able to track their progress in a course. 

For example, the acceptance criteria include the ability to see which modules have been completed, the percentage of assembled modules, and the ability to mark a module as complete.

To use these examples as a reference, you can analyze them based on the 3 C’s. 

Ask yourself:

• Is the user story clear and concise?

• Does it accurately reflect the needs of the user?

• Could it lead to a productive conversation about how to implement the feature?

• Can it be confirmed with testable acceptance criteria? 

By analyzing these examples, you can better understand what makes a good user story and use that knowledge to create your own user stories.

How To Gather User Stories?

While writing user stories, don’t forget to note down the methods you can use to gather them.

Following are some ways you can collect user stories:

Through Interviews

Ask relevant questions to a diverse audience will help you know what new features you need to add.

Or, if the product is new, then asking the potential customers open-ended questions will be beneficial. 

Through Observation

Have an eye for details and observe how customers use the product. Such observation can also help you write user stories. 

By Conducting Surveys

Survey with questionnaires related to the user stories. Share it online or in hard copy to derive results. 

Getting your hands on the top product management software to collect customer feedback using pre-built surveys and audience tools is recommended.

Prototyping

Show your agile user story ideas to the teams. Then, open the platform for discussion through PowerPoint presentations. 

Conducting Workshops

Another way of gathering and writing user stories is by brainstorming ideas.

A session with participants discusses as many user stories as possible. It would be best not to assess the ideas while in the workshop.

This way, having a pool of user stories in place becomes more effortless. 

Use Cases vs User Stories

Definition of Use Cases

A use case is a methodology used in software engineering to define and describe how a user or an actor interacts with a system or software application to achieve a specific goal. It typically involves creating a scenario that outlines the user’s steps and the expected outcome. 

The use case describes the system’s behavior and how it responds to various inputs or actions from the user. Use cases can be used to identify requirements, validate design decisions, and ensure that the software system meets the user’s needs.

Now let’s address few confusions and clear them up

Is a user story the same thing as a use case? 

Although they share similarities, user stories and use cases are not interchangeable. However, they both can identify users and describe the goal, but they serve different purposes. 

The differences are as follows: 

Degree of Detail

User stories usually are, and purposefully, vaguer. They provide a simple description of what a feature should help a user do. Thus, it leaves it open to interpretation. 

Use cases cover more ground by showing how the user should interact with the system. They also cover how the system should reciprocate.

They go into more detail about the individual steps in a feature-driven development. 

Sprint Length 

User stories can generally fit into one sprint. They contain features or details small enough to be completed as quickly as possible. A team can even get through multiple user stories in one sprint. 

Use cases tend to cover several sprints, providing an overview of a more extensive functionality. They generally list out each step of a feature’s process. 

Structure

The user story is just a line or two of a statement about what the user wants to achieve. You can write that on a simple index card, making them quick and easy to create. 

On the other hand, use cases can take more time to put together. That’s because they detail each step and represent it in a diagram. This makes use cases potentially more helpful in a practical sense for identifying friction points in the process. 

However, you can also do this by combining user stories and flows. It helps map out different screens a user goes through in the process. 

When To Use User Stories or Use Cases?

When faced with which to use – user stories or use cases, it all depends on your team, its size, and your product. 

The rule of thumb to decide is to discuss with all stakeholders in the product to hash out the pros-cons analysis of each mapping. 

At Chisel, we always advocate keeping things agile, but every scenario is different. 

If all else fails, using them together is usually your best bet if done strategically rather than one or the other. Combined, they keep the plain language tone of user stories.

However, it can go into extra detail about system functionalities to satisfy user goals. Some experts even recommend starting with use cases first.

Later, you can move on to user stories at later iterations once the foundation is sound. To break it down, you’d be using use cases to create the fundamental features of the product.

And then, you will use user stories when adding the extra features to speed up further development.

Conclusion

In conclusion, user stories are a vital tool for Agile software development teams to understand the needs and requirements of their end-users. By putting the end-users at the center of the development process, teams can ensure that they are developing software that meets the needs of the people who will use it. 

You are familiar with an agile user story and how to write good user stories. 

Learn about the anatomy of a user story, and you are on the way to writing better user stories.