How to Write User Stories (in Agile): The Three C’s and Examples

Agile User Story

What Is a User Story?

A user story is a short, simple explanation of a software feature written by someone who desires a new capability. 

A user story articulates how a software feature will provide value to the customer.

A user story describes the type of user, what they want, and why. It helps create a simplified description of a requirement. 

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

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

What Is an Agile User Story?

In the agile framework, a user story is the smallest unit of work. 

It is an end goal and not a feature, expressed from the user’s perspective. 

The purpose of an agile user story is 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 with 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 rather, you add the team’s requirements later once agreed. 

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.

What Are the 3C’s in User Stories?

An initial set of user stories is part of the discovery process. The team continuously adds additional user stories as needed during delivery.

Defining user stories is a convenient way to capture detailed requirements while focusing on user goals. That’s why, they can be so successful in determining the value for your users. 

A good user story consists of three elements, commonly referred to as the agile three c’s. 

3C’s in User Stories
3C’s in User Stories

Card

Although you can take this literally, the idea behind the first C, card, refer 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 should have enough information to plan, identify the need, and remind the team of the overall story. 

This is the format they should follow:

“As a [particular user], I want to [perform this action], so that [I can achieve this goal].”

The focus should be to gather 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. But 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. 

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 also include electronic communications through email, internal chat, or any online connection 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.

What Is a Good User Story?

INVEST is the acronym that 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 in 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, keep in mind 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. 

You can easily distinguish between high and low effort stories when estimating agile user 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 efforts is difficult to estimate and negotiate.

Testable

One of the best indicators of writing better user stories is testable. 

When a customer cannot tell if you have implemented their story, the entire team’s effort may be in vain. 

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

How To Write Good User Stories?

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.

Put Users First

As we’ve discussed, and you can probably guess by now, a user story describes how a customer employs the product from their perspective. 

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

Do adequate 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 and a picture, relevant characteristics, behaviors, attitudes, and an overall goal. 

You can understand the goal as a benefit a persona wants to achieve. 

The question that you need to ask is, “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. 

It’s vital that the product owner and the team 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’ when it comes to user stories. 

Avoid confusing and overly fluffy terms. Don’t forget to use an active voice. 

Focus on the important parts. 

Leave out everything else. 

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

As <persona>,

I want <what?>

So that <why?>

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 specifically comes in handy when describing new products and features. It allows a product manager to capture the rough outline while buying time to learn more about how to address users’ needs

It also saves time because instead of having multiple disjointed, detailed stories in the product backlog, you have an epic organizing them accordingly. 

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 done. 

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 to have five acceptance criteria for detailed stories. 

Use Paper Cards

Initially, user stories were born from extreme programming and literature around it talking about story cards rather than user stories. It is because the stories were captured 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. 

Whether in Chisel or physically on walls, having visibility fosters collaboration and transparency. 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 help capture product functionality but compliment them with other techniques like 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 are about enabling you to move fast and develop as quickly as possible. 

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

Asking relevant questions to a diverse audience will help you know what new features you need to add. Or, if the product is a new one, then asking the potential customers open-ended questions will be beneficial. 

Through Observation

Having an eye for details and observing how customers use the product can also help you write user stories. 

By Conducting Surveys

Doing a survey with questionnaires related to the user stories and sharing it online or in hard copy is said to derive results. 

Prototyping

Show your agile user story ideas to the teams and open the platform for discussion through PowerPoint presentations and so on. 

Conducting Workshops

Another way of gathering and writing user stories is by brainstorming. 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, it becomes easier to have a pool of user stories in place. 

User Story vs. Use Case

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 simplified description of what a feature should help a user do, leaving it open to interpretation. 

Use cases cover more ground by showing how the user ought to interact with the system and how the system should reciprocate. They go into more detail about the individual steps in a feature’s process. 

Sprint Length 

User stories can generally fit into one spring as 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 as they provide 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 as they detail each step and are often represented 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 using a combination of 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. But it can go into extra detail about system functionalities to satisfy user goals. 

Some experts even recommend starting with use cases first and then moving on to user stories at later iterations once the basis 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.

What Are the Good User Story Examples?

Let’s have a look at good user story examples. This way, you will also understand an agile user story format. 

  • As an (audience), I want (a review button) so that (I can see how other customers rate the product before purchasing).
  • As a (regular customer/buyer), I want (a notification option once the item is shipped) so that (I can make the necessary arrangements to pick it up).

Since you can write an agile user story at varying degrees of detail, sometimes a large functionality is fit into one user story. This is called the epic.

  • For example, As a manager, I want to get an information-based report to know when the teams need help in terms of resources. 

You can divide this epic into various or even hundreds of user stories such as:

  • As a manager, I want a datasheet so that I can verify which teams are working on what tasks
  • As a manager, I want a daily report to avoid piling up until the end of the month. 

Conclusion

Now 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.

Crafting great product requires great tools. Try Chisel today, it's free forever.